Q? system wide variables
Hi, I need to track the 'fake' amount of video memory in total, allocated and left for Directx 9 and would like to track it across wine so that DDraw, DirectX, DxDiag and X11 driver can all sing from the same song sheet. What's the best place to do this? is the registry code fast enough or should I add a new function to the X11 driver so that I can request and release 'fake' video memory and make all other AvailableVideoMemory requests ask X11 driver? I would expect the use to be able to override by the initial amount, even if there's code that detects it since wine,X and openGL manage video memory differently to windows, direct draw and D3D. ___________________________________________________________ ALL-NEW Yahoo! Messenger - all new features - even more fun! http://uk.messenger.yahoo.com
On Sat, 29 Jan 2005 19:44:33 +0000, Oliver Stieber wrote:
What's the best place to do this? is the registry code fast enough or should I add a new function to the X11 driver so that I can request and release 'fake' video memory and make all other AvailableVideoMemory requests ask X11 driver?
I would expect the use to be able to override by the initial amount, even if there's code that detects it since wine,X and openGL manage video memory differently to windows, direct draw and D3D.
Yes, the registry is fine though if you are going to detect this at startup it may be worth making it volatile. I'm not sure it makes sense to have a config option here. How many people will think to adjust it? If so though a (non volatile) registry key is the way forward.
Oliver Stieber wrote:
Hi, I need to track the 'fake' amount of video memory in total, allocated and left for Directx 9 and would like to track it across wine so that DDraw, DirectX, DxDiag and X11 driver can all sing from the same song sheet.
What's the best place to do this? is the registry code fast enough or should I add a new function to the X11 driver so that I can request and release 'fake' video memory and make all other AvailableVideoMemory requests ask X11 driver?
I would expect the use to be able to override by the initial amount, even if there's code that detects it since wine,X and openGL manage video memory differently to windows, direct draw and D3D.
How will this affect ReactOS? They don't use X11. They even plan on loading native binary 3D drivers. regards, Jakob
Jakob Eriksson wrote:
Oliver Stieber wrote:
Hi, I need to track the 'fake' amount of video memory in total, allocated and left for Directx 9 and would like to track it across wine so that DDraw, DirectX, DxDiag and X11 driver can all sing from the same song sheet.
What's the best place to do this? is the registry code fast enough or should I add a new function to the X11 driver so that I can request and release 'fake' video memory and make all other AvailableVideoMemory requests ask X11 driver?
I would expect the use to be able to override by the initial amount, even if there's code that detects it since wine,X and openGL manage video memory differently to windows, direct draw and D3D.
How will this affect ReactOS?
They don't use X11. They even plan on loading native binary 3D drivers.
AFAIK, they plan to completely rewrite the D3D layer to not use OpenGL at all and use the native D3D interface, so it won't affect ReactOS at all. Rob
On Sun, Jan 30, 2005 at 01:00:21AM +0100, Jakob Eriksson wrote:
They don't use X11. They even plan on loading native binary 3D drivers.
And this means that they cannot use Wine's Direct3D code as it does not respect Microsoft's internal APIs between 'user code' and the various HAL / HEL / DDKs and stuff. Lionel -- Lionel Ulmer - http://www.bbrox.org/
What's the best place to do this? is the registry code fast enough or should I add a new function to the X11 driver so that I can request and release 'fake' video memory and make all other AvailableVideoMemory requests ask X11 driver?
For me, I think the X11 driver should be the best place for it (at least the one the more 'Windows-like' as all our D3D, DDraw, .... implementations should be layered upon this driver). Lionel -- Lionel Ulmer - http://www.bbrox.org/
participants (5)
-
Jakob Eriksson -
Lionel Ulmer -
Mike Hearn -
Oliver Stieber -
Rob Shearman