Hi,
I'd like to get up the discussion for the D3DXHANLE in the ID3DXConstantTable again. There were several tries in the past, but there wasn't made a decision for one solution.
My opinion about the handles is, that they have to allow at least the following options: 1. D3DXHANDLEs have to be global (not local to a ID3DXConstantTable), so the way the effect interface does it is not an ideal option for the ID3DXConstantTable 2. D3DXHANDLEs could also be strings and thus it is a requirement that this could be detected (at least for !D3DXCONSTTABLE_LARGEADDRESSAWARE)
Ideally we may handle all D3DXHANDLEs the same way. Some possible solutions are listed in [3].
Any thoughts which way is preferred?
Cheers Rico
References: [1] http://www.winehq.org/pipermail/wine-devel/2010-April/082900.html [2] http://www.winehq.org/pipermail/wine-patches/2011-July/104325.html [3] http://www.winehq.org/pipermail/wine-devel/2011-July/091091.html
2012/1/5 Rico Schüller kgbricola@web.de:
Ideally we may handle all D3DXHANDLEs the same way. Some possible solutions are listed in [3].
Any thoughts which way is preferred?
It's not entirely clear to me from any of those links why simply using a normal handle table wouldn't work.
Am 04.01.2012 13:23, schrieb Henri Verbeet:
2012/1/5 Rico Schüllerkgbricola@web.de:
Ideally we may handle all D3DXHANDLEs the same way. Some possible solutions are listed in [3].
Any thoughts which way is preferred?
It's not entirely clear to me from any of those links why simply using a normal handle table wouldn't work.
I'm not sure what you mean by a "normal handle table".
Do you mean a list?
Cheers Rico
2012/1/5 Rico Schüller kgbricola@web.de:
I'm not sure what you mean by a "normal handle table".
Do you mean a list?
It's pretty much just a table of handles. There are a couple of different variants spread over the Wine source. For example, http://source.winehq.org/git/wine.git/blob/HEAD:/dlls/ddraw/main.c#l50 is what ddraw uses.
Am 04.01.2012 17:26, schrieb Henri Verbeet:
2012/1/5 Rico Schüllerkgbricola@web.de:
I'm not sure what you mean by a "normal handle table".
Do you mean a list?
It's pretty much just a table of handles. There are a couple of different variants spread over the Wine source. For example, http://source.winehq.org/git/wine.git/blob/HEAD:/dlls/ddraw/main.c#l50 is what ddraw uses.
Well that's a list, isn't it? So we are talking about the same thing. I'm not sure that's the best solution. Since you could pass pointers to strings as handles, I'd like to show the following example: char *name="test"; address may be: name -> 0x80484c4 Now what happens if the address is equal the index of another variable? You'd get the wrong variable. You couldn't safely say from the value if it is a name or a handle! So the only option I see is to use the address of the handle as index, which would require a sorted list or something like a rbtree and also would be cpu expensive for comparison if the "index" is in the list. Keep in mind the list could get big and the handles have to be compared every usage (maybe several times per frame). You'd have to compare against all handles, not only the small amount in one shader... and each element and struct member has it's own handle. That's why I think a table wouldn't do the trick. What do you think?
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.
Cheers Rico
2012/1/5 Rico Schüller kgbricola@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.
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.)
Am 05.01.2012 06:09, schrieb Henri Verbeet:
2012/1/5 Rico Schüllerkgbricola@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
2012/1/5 Rico Schüller kgbricola@web.de:
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.
Probably a FIXME, but yeah. I suppose if needed on 64-bit we could just map 2GB of address space just to prevent anything else from allocating things in that range. Or perhaps 64-bit d3dx9 really is just broken. But as far as I'm concerned it's not something we really need to worry about until we have applications running out of handles, as long as it's obvious when we hit that case.
2012/1/5 Rico Schüller kgbricola@web.de:
is a name or a handle! So the only option I see is to use the address of the handle as index, which would require a sorted list or something like a rbtree and also would be cpu expensive for comparison if the "index" is in the list. Keep in mind the list could get big and the handles have to be
Actually, as an aside, rb-trees scale pretty well, but they're a relatively big hammer for the kind of problem you're trying to solve.
-
Henri Verbeet -
Rico Schüller