D3DXHANDLE for ID3DXConstantTable

[Rico Schüller]

Am 05.01.2012 06:09, schrieb Henri Verbeet:
> 2012/1/5 Rico Schüller<kgbricola at web.de>:
>> char *name="test"; address may be: name ->  0x80484c4
>> Now what happens if the address is equal the index of another variable?
> You're not really supposed to have string pointers in the first MB or
> so of your address space.
Yes, that's true, but please have a look at the attached test case. You 
need around 1200000 D3DXHANDLEs and that assumption will likely fail and 
it could be very hard to debug. These are a lot! Well these are ~150 
shaders with all 8192 variables used. Native d3dx9_36 on wine could cope 
with around 15000 shaders of that size. I'm not sure if we could get a 
problem with that. Maybe I'm just seeing this too strict.
>> The detection by something like the address //((UINT_PTR)ptr)&  (1<<
>> (sizeof(UINT_PTR)*8-1))// (see
>> http://www.winehq.org/pipermail/wine-devel/2010-April/082900.html ) may not
>> be save either, but it is a lot better in concerns of speed and it is what
>> some people think native does! So it might be the most compatible way to do
>> it.
> It would probably break down pretty badly on 64-bit. Nevertheless,
> with a handle table it's trivial to switch from one scheme to the
> other by simply changing the way you map table indices to handle
> values. (I.e. you'd just do something like adding 0x80000000 or
> inverting the index to get the handle.)
Sure, it could be done that way. So we may start using normal indices 
(0..x) and put out a warning if there are too much handles around. That 
way we may see if apps use that much handles.

Cheers
Rico
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: d3dx_handle_test
URL: <http://www.winehq.org/pipermail/wine-devel/attachments/20120105/31251c65/attachment.ksh>