Re: Driver-supported DirectX
On 23/11/2007, Stefan Dösinger [EMAIL PROTECTED] 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.
Re: Driver-supported DirectX
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. signature.asc Description: This is a digitally signed message part.
Re: Driver-supported DirectX
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. signature.asc Description: This is a digitally signed message part.
Re: Driver-supported DirectX
On 23/11/2007, Stefan Dösinger [EMAIL PROTECTED] 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.
Re: Driver-supported DirectX
On 23/11/2007, Remco [EMAIL PROTECTED] 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
