d3dx9: ID3DXConstantTable

[Rico Schüller]

On 22.08.2012 12:23, Józef Kucia wrote:
> On Tue, Aug 21, 2012 at 10:52 PM, gurketsky <gurketsky at googlemail.com
> <mailto:gurketsky at googlemail.com>> wrote:
>
>     I just like to present the state of the ID3DXConstantTable
>     implementation, so that possibly no work is done twice. This goes
>     specifically to Józef. I'm not sure what's the plan on this. There
>     are two problems which arise and I did not had time to sort those
>     out, yet.
>
>
> Thanks for notifying me. I was about to write some tests for structures
> in constant tables. I see that you've already written such tests.
>
> Cheers,
> Józef Kucia

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).

To tackle the problem:
1. The handle and table mixing could be worked around by using a global 
list for all tables and searching the handles in there. That should be 
easy to add. The problem I see with that, might be speed related, when 
we have a lot of handles, searching the list will be slow. Through, I'm 
fine with that solution and would add it. It will show, if it really is 
so slow...

2. But the other solution isn't dead for me, yet. I had another look at 
the D3DXHANDLE usage and the question what the hell is 
D3DXCONSTTABLE_LARGEADDRESSAWARE used for? It was said, it's bad and 
broken, but I haven't seen why, just that it is ugly, but I couldn't see 
a technical reason not to do so. What's specifically the problem:

The argument is, that D3DXHANDLES are distinguished from strings by 
using the highest bit (bit #31). Thus with LARGEADDRESSAWARE the usage 
of stings as D3DXHANDLEs is not allowed anymore (see 
http://msdn.microsoft.com/en-us/library/windows/desktop/bb943959%28v=vs.85%29.aspx). 
Also this would speed up the detection of a handle dramatically, well it 
doesn't check for validness, but native doesn't do that, if you pass a 
garbled handle, it will crash.

D3DXHANDLE handle_from_constant(struct ctab_constant *constant)
{
     if (largeadressaware && constant) return (D3DXHANDLE)constant;
     if (constant) return (D3DXHANDLE)((UINT_PTR)constant | 0x80000000);
     return NULL;
}
struct ctab_constant *is_valid_constant(struct ID3DXConstantTableImpl 
*table, D3DXHANDLE handle)
{
     if (largeadressaware) return (struct ctab_constant *)handle;
     if ((UINT_PTR)handle >> 31) return (struct ctab_constant 
*)((UINT_PTR)handle & 0x7fffffff);
     return get_constant_by_name(table, NULL, handle);
}

According to http://en.wikipedia.org/wiki/Virtual_address_space:
32bit on 32bit without LARGEADDRESSAWARE: has only 2gb (default 32bit)
32bit on 64bit without LARGEADDRESSAWARE: has only 2gb (default 32bit)
64bit on 64bit without LARGEADDRESSAWARE: has only 2gb
32bit on 32bit with LARGEADDRESSAWARE: has 3gb
32bit on 64bit with LARGEADDRESSAWARE: has 4gb
64bit on 64bit with LARGEADDRESSAWARE: has 8tb (default 64bit)

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?

I hope this helps you to make the correct decisions.

Cheers
Rico