d3dx9: ID3DXConstantTable

[Józef Kucia]

On Wed, Aug 22, 2012 at 2:45 PM, Rico Schüller <kgbricola at web.de> wrote:

> Well, I just had a closer look again. My speed test triggers a problem, so
> it's not really comparable. But it looks like native only allocates
> handles, if it really needs them. So I'm not sure we like to go the same
> approach or if it is fine allocating them all like I've done that. I fixed
> the test and native speed advantage was blown away. Although, if that's
> fine with your opinion, you could reuse the code or I could clean it up a
> bit and send it. I haven't send it and improved it, yet, because the
> problem with solution 1. or 2. isn't solved for me. I'm a little bit
> against version 1., because I think speed might be an issue and no one had
> a technical argument against 2. I don't think a extra handle list for
> handles with "small" values is the way to got, because it may also hit the
> values where strings could be in memory. The extra handle list would be 3.,
> but I think it needs a lot more memory for just adding a "layer" for
> checking the handles. Thus 2. is a lot better than 3. (which I haven't
> explained in detail).
>

I would prefer you to clean it up submit it. I hope it gets committed this
time.


> So in cases, where the exe is linked with LARGEADDRESSAWARE, d3dx9 would
> have to be used with D3DXCONSTTABLE_LARGEADDRESSAWARE. That way it's the
> same for os with 32bit and 64bit. The only problem I see, nowhere is said,
> that the 2gb will always be the lowest 2gb. But my tests showed, that I
> always get the lower 31bit of addresses in my test runs when allocating
> memory. Thus I'm very unlucky by not getting a higher address or this might
> be the way it works on windows. Has anyone a technical argument against
> this solution?
>

It seems fine to me. A program compiled without *LARGEADDRESSAWARE* should
get all the memory allocated below the 2 GB limit (see
http://msdn.microsoft.com/en-us/library/windows/desktop/aa384271%28v=vs.85%29.aspx
).

-- 
Józef Kucia
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.winehq.org/pipermail/wine-devel/attachments/20120823/12ce369d/attachment.html>