On Wed, Aug 22, 2012 at 2:45 PM, Rico Schüller <kgbric...@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