I don't know the first thing about driver- and DirectX-programming, so please forgive (and point out) any mistakes.
As a reader of this list I'm wondering; there are quite a few problems that come from the fact that DirectX isn't 1:1 translatable to OpenGL. How about talking to some guys from the GPU-driver department about creating a driver-interface that gives you the right hooks. I guess Parallels and Transgaming would also be interested in such a development. I can imagine that the Nouveau-devs and Xorg-radeon-devs would be more than happy to listen.
This goes beyond the scope of the Wine project I think. But since Wine has the higher level part of DirectX documented and implemented on top of OpenGL, wouldn't this be the place to start an independent library? Codeweavers has a lot of knowledge about Windows, DirectX and Linux. Only Microsoft itself would be a better choice, but I don't think they really care that much about Linux. ;)
This would mean that DirectX would be as native to Linux and OSX (and friends) as it would be for Windows. It would be an actual reliable platform that could be used by game developers. It would de-Windows-ize DirectX. Maybe NVIDIA, ATI and Intel would also be interested. They could sell their expensive next-gen cards to those 5% that don't run Windows if games would actually be released for non-Windows OSes.
Or are there really compelling technical reasons to wrap around OpenGL? I can think of the Compiz-issue. Similarly, Microsoft stated that they have to wrap OpenGL around DirectX on Windows, to be able to use both OpenGL and DirectX at the same time (for Aero). But I suspect that this implementation just developed naturally because messing with the drivers would be unthinkable way back when.
Remco
____________________________________________________________________________________ Get easy, one-click access to your favorites. Make Yahoo! your homepage. http://www.yahoo.com/r/hs
On 23/11/2007, Remco remco47@yahoo.com wrote:
I don't know the first thing about driver- and DirectX-programming, so please forgive (and point out) any mistakes.
As a reader of this list I'm wondering; there are quite a few problems that come from the fact that DirectX isn't 1:1 translatable to OpenGL. How about talking to some guys from the GPU-driver department about creating a driver-interface that gives you the right hooks. I guess Parallels and Transgaming would also be interested in such a development. I can imagine that the Nouveau-devs and Xorg-radeon-devs would be more than happy to listen.
This sounds interesting.
It may be useful contacting the nouveau (open source NVidia 3D driver reverse engineering project) development team to see if they can add OpenGL extensions for DirectX functionality.
Intel have official open source drivers for Linux, so it would be useful contacting their developers as well.
Also, with the AMD merger, the radeon drivers are being released as open source. There are also the reverse engineered radeon drivers, so they might be interested. And with the graphics card specs being published, this might make it easier to do this.
This goes beyond the scope of the Wine project I think. But since Wine has the higher level part of DirectX documented and implemented on top of OpenGL, wouldn't this be the place to start an independent library? Codeweavers has a lot of knowledge about Windows, DirectX and Linux. Only Microsoft itself would be a better choice, but I don't think they really care that much about Linux. ;)
This would mean that DirectX would be as native to Linux and OSX (and friends) as it would be for Windows. It would be an actual reliable platform that could be used by game developers. It would de-Windows-ize DirectX. Maybe NVIDIA, ATI and Intel would also be interested. They could sell their expensive next-gen cards to those 5% that don't run Windows if games would actually be released for non-Windows OSes.
Or are there really compelling technical reasons to wrap around OpenGL? I can think of the Compiz-issue. Similarly, Microsoft stated that they have to wrap OpenGL around DirectX on Windows, to be able to use both OpenGL and DirectX at the same time (for Aero). But I suspect that this implementation just developed naturally because messing with the drivers would be unthinkable way back when.
It is only Windows applications that use DirectX. All of the Linux infrastructure (Xgl, Compiz, etc.) is built around OpenGL. Therefore, for Wine to integrate into the Linux desktop infrastructure, DirectX needs to map onto OpenGL.
I would say that the best approach would be cooperating with the nouveau, Intel and Radeon Linux graphics driver developers to add the extensions needed to support DirectX. The Intel and Radeon developers would be useful to have on board, as they might be able to give information on how they are implementing DirectX: this will allow us to cooperate with the Linux driver teams to get the OpenGL extensions needed.
As for the nouveau team, it would be interesting to get the renouveau reverse engineering driver running on Windows to reverse engineer the DirectX driver and develop the corresponding OpenGL extensions.
- Reece
The problem with all that is that DirectX is tightly integrated into Windows-specific components, and therefore the only level that it could exist is along the rest of the Wine layer. I also wish to note that AMD isn't releasing radeon drivers, they had Novell develop a WHOLE NEW driver for the ATI cards. Really the best way to deal with issues with DirectX and OpenGL is to add extensions to OpenGL to expose the functionality in the hardware that can be translated to DX calls. In Linux, I suppose this wouldn't be a big issue since the Mesa stuff could be modified to expose the functionality missing. If Wine can take advantage of compiz or AIGLX functionality, then that is wonderful. AFAIK, Wine does not utilize compiz or AIGLX functionality, rather it goes straight to Mesa? I am not a programmer, so I don't really know.
On Nov 23, 2007 2:51 AM, Reece Dunn msclrhd@googlemail.com wrote:
On 23/11/2007, Remco remco47@yahoo.com wrote:
I don't know the first thing about driver- and DirectX-programming, so
please forgive (and point out) any mistakes.
As a reader of this list I'm wondering; there are quite a few problems
that come from the fact that DirectX isn't 1:1 translatable to OpenGL. How about talking to some guys from the GPU-driver department about creating a driver-interface that gives you the right hooks. I guess Parallels and Transgaming would also be interested in such a development. I can imagine that the Nouveau-devs and Xorg-radeon-devs would be more than happy to listen.
This sounds interesting.
It may be useful contacting the nouveau (open source NVidia 3D driver reverse engineering project) development team to see if they can add OpenGL extensions for DirectX functionality.
Intel have official open source drivers for Linux, so it would be useful contacting their developers as well.
Also, with the AMD merger, the radeon drivers are being released as open source. There are also the reverse engineered radeon drivers, so they might be interested. And with the graphics card specs being published, this might make it easier to do this.
This goes beyond the scope of the Wine project I think. But since Wine has the higher level part of DirectX documented and implemented on top of OpenGL, wouldn't this be the place to start an independent library? Codeweavers has a lot of knowledge about Windows, DirectX and Linux. Only Microsoft itself would be a better choice, but I don't think they really care that much about Linux. ;)
This would mean that DirectX would be as native to Linux and OSX (and
friends) as it would be for Windows. It would be an actual reliable platform that could be used by game developers. It would de-Windows-ize DirectX. Maybe NVIDIA, ATI and Intel would also be interested. They could sell their expensive next-gen cards to those 5% that don't run Windows if games would actually be released for non-Windows OSes.
Or are there really compelling technical reasons to wrap around OpenGL?
I can think of the Compiz-issue. Similarly, Microsoft stated that they have to wrap OpenGL around DirectX on Windows, to be able to use both OpenGL and DirectX at the same time (for Aero). But I suspect that this implementation just developed naturally because messing with the drivers would be unthinkable way back when.
It is only Windows applications that use DirectX. All of the Linux infrastructure (Xgl, Compiz, etc.) is built around OpenGL. Therefore, for Wine to integrate into the Linux desktop infrastructure, DirectX needs to map onto OpenGL.
I would say that the best approach would be cooperating with the nouveau, Intel and Radeon Linux graphics driver developers to add the extensions needed to support DirectX. The Intel and Radeon developers would be useful to have on board, as they might be able to give information on how they are implementing DirectX: this will allow us to cooperate with the Linux driver teams to get the OpenGL extensions needed.
As for the nouveau team, it would be interesting to get the renouveau reverse engineering driver running on Windows to reverse engineer the DirectX driver and develop the corresponding OpenGL extensions.
- Reece
Hi, Implementing Direct3D at driver level won't magically fix things. The issues will be still the same: Undocumented or incorrectly documented behavior of Direct3D and broken apps which rely on defined results in per se undefined situations. There are only a handful of cases where OpenGL<->Direct3D differences make problems, like non power of two textures or flat shading. Those could as well be fixed with proposing an additional extension, instead of turning everything upside down in Linux(and at the same time MacOS, Solaris, *BSD).
Hardware doesn't magically execute Direct3D 1:1. In fact, Windows drivers essentially do the same: Map D3D to a hardware interface which is a hybrid of OpenGL and D3D. You can see this by looking at nvidia extensions: They have a GL extension for almost every single bit of d3d functionality that does not map 1:1 to gl.
On 23/11/2007, Stefan Dösinger stefan@codeweavers.com wrote:
Hi, Implementing Direct3D at driver level won't magically fix things. The issues will be still the same: Undocumented or incorrectly documented behavior of Direct3D and broken apps which rely on defined results in per se undefined situations. There are only a handful of cases where OpenGL<->Direct3D differences make problems, like non power of two textures or flat shading. Those could as well be fixed with proposing an additional extension, instead of turning everything upside down in Linux(and at the same time MacOS, Solaris, *BSD).
Hardware doesn't magically execute Direct3D 1:1. In fact, Windows drivers essentially do the same: Map D3D to a hardware interface which is a hybrid of OpenGL and D3D. You can see this by looking at nvidia extensions: They have a GL extension for almost every single bit of d3d functionality that does not map 1:1 to gl.
What Stefan said :-)
Just to add something to that, most of the issues that are there are with older versions of Direct3D and fixed function. The more modern functionality is relatively easier to translate because D3D and GL simply expose the programmability of the hardware.
Am Freitag, 23. November 2007 12:25:34 schrieb H. Verbeet:
Just to add something to that, most of the issues that are there are with older versions of Direct3D and fixed function. The more modern functionality is relatively easier to translate because D3D and GL simply expose the programmability of the hardware.
Not quite, there are a few issues at shader level as well. One issue that comes to my mind are the 10 varyings vs 8+2 colors in opengl. It is a driver limitation actually, but encouraged by the GLSL spec. An architectural problem is that OpenGL does not support an up to date assemler shader interface. And all shaders are compiled and linked at runtime, causing a short rendering freeze whenever a new shader is used.
It may be useful contacting the nouveau (open source NVidia 3D driver reverse engineering project) development team to see if they can add OpenGL extensions for DirectX functionality.
This sounds like a nice idea, but in reality we've been talking about getting various X11 or opengl extensions added to $SOFTWARE and it never happened.
On 23/11/2007, Stefan Dösinger stefan@codeweavers.com wrote:
Am Freitag, 23. November 2007 12:25:34 schrieb H. Verbeet:
Just to add something to that, most of the issues that are there are with older versions of Direct3D and fixed function. The more modern functionality is relatively easier to translate because D3D and GL simply expose the programmability of the hardware.
Not quite, there are a few issues at shader level as well. One issue that comes to my mind are the 10 varyings vs 8+2 colors in opengl. It is a driver limitation actually, but encouraged by the GLSL spec. An architectural problem is that OpenGL does not support an up to date assemler shader interface. And all shaders are compiled and linked at runtime, causing a short rendering freeze whenever a new shader is used.
Well, sure there are issues, but generally those are easier to fix than in fixed function. I don't consider the lack of an asm interface much of an issue... it wouldn't correspond directly to the hardware anyway (and neither does d3d shader asm). Linking time *is* an issue, but I suspect GL3 will help a bit there.
It may be useful contacting the nouveau (open source NVidia 3D driver reverse engineering project) development team to see if they can add OpenGL extensions for DirectX functionality.
This sounds like a nice idea, but in reality we've been talking about getting various X11 or opengl extensions added to $SOFTWARE and it never happened.
It would probably have to wait until nouveau actually properly supports 3D.
-
H. Verbeet -
King InuYasha -
Reece Dunn -
Remco -
Stefan Dösinger