November 2007 - Wine-Devel - list.winehq.org

Re: Driver-supported DirectX

by H. Verbeet

On 23/11/2007, Stefan Dösinger <stefan(a)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.

Nov. 23, 2007

Re: Driver-supported DirectX

by Stefan Dösinger

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.

Nov. 23, 2007

Re: Start: Convert start to Unicode. [try5]

by Anatoly Lyutin

Alexandre Julliard wrote: > No, what you need is one function for errors that can happen in normal > usage (file not found, invalid option etc.) that is Unicode and > localized, and one function for internal errors (LoadString failures > etc.) that simply uses WINE_ERR with an English message. > > I send new version according your requirements to patches-lists. Have I made all correctly? -- Best regards Anatoly Lyutin.

Nov. 23, 2007

Re: WineD3D: Implement detection of ATI cards with Mesa DRI drivers [try 3]

by Roderick Colenbrander

> Roderick Colenbrander wrote: > > I would really ask you to use the D3DX_CAPABLE() macros as not using > them can result in bad problems. E.g. a game assuming a certain d3d > functionality is there while it isn't backed by any GL extension. > > > You certainly do have a point. I will redo the patch a bit later, but > before that, I have a couple of questions. > > 1) Checking real capabilities surely can be a good way to approximate > the level of used hardware. But could these D3DX_CAPABLE() macros be > considered reliable enough to use just them alone (and not the DRI > module names) for conceiving the card model? If this is so, then > checking of the Mesa renderer string could remain only for detection > that the card is from ATI (because it does not give any precise info > anyway). I have done a lot of tests to come to this list of extensions and it is quite good. So the purpose of the macros is to get an impression of what roughly the d3d capabilities of a card are and using GL info (vendor / renderer string) a more exact match is found. But this is not needed. Also note that thanks to this mechanism even if the card isn't known it is at least reported as a card with the same minimum requirements. (A geforce10 or whatever would default to some basic d3d9 card but that is better than nothing) > 2) Are there any plans to add D3D9B_CAPABLE and D3D9C_CAPABLE (and maybe > D3D10_CAPABLE too)? These would immensely help to identify the newer > cards. Currently, without such macros, the detection code can't safely > report that a card is anything more than the ATI's Direct3D 9 > lowest-common denominator, Radeon 9500. (See > http://en.wikipedia.org/wiki/Radeon for a table of models and their > DirectX versions). D3d10 support is relatively easy to add (check for the geometry shader extension) but only nvidia exports that yet. Checking for d3d9b/d3d9c is more complicated as the differences lie in the number of shader constants and things like that. Perhaps I will extend it with that but I need to dive back into the numbers (some drivers aren't clear about their specifications and that makes it hard) Note that d3d10 doesn't export the gpu capabilities and device name anymore, so it is only needed for <=d3d9. Roderick -- Der GMX SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen! Ideal für Modem und ISDN: http://www.gmx.net/de/go/smartsurfer

Nov. 23, 2007

Re: Driver-supported DirectX

by King InuYasha

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(a)googlemail.com> wrote: > On 23/11/2007, Remco <remco47(a)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 > > >

Nov. 23, 2007

Re: Driver-supported DirectX

by H. Verbeet

On 23/11/2007, Stefan Dösinger <stefan(a)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.

Nov. 23, 2007

Re: Driver-supported DirectX

by Stefan Dösinger

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.

Nov. 23, 2007

Re: Driver-supported DirectX

by Reece Dunn

On 23/11/2007, Remco <remco47(a)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

Nov. 23, 2007

Re: [msvcrt] short tty reads don't imply EOF

by Damjan Jovanovic

On Nov 21, 2007 3:12 PM, Alexandre Julliard <julliard(a)winehq.org> wrote: > "Damjan Jovanovic" <damjan.jov(a)gmail.com> writes: > > > Changelog: > > * For ttys, short reads don't mean we're at the end of the file. > > That's not limited to ttys, other file types can have short reads too. Yes, but removing the entire block of code that handles short reads causes many msvcrt tests to fail :-). There is no general way to tell you're at the end of the file, before you actually get there (by read() returning 0). But, you can't read ahead, because that won't work for ttys. Suggestions? While on the topic of reading, is there any reason why ReadFile() calls ReadConsoleA() for console handles, but ReadFileEx() does not? > -- > Alexandre Julliard > julliard(a)winehq.org > Damjan

Nov. 23, 2007

Driver-supported DirectX

by Remco

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

Nov. 23, 2007