Direct3D Performance Improvements Coming To Wine

[artivision]

No, not a CodeWeavers guy, although I do interact with some of them and know a few wine developers, as well.... Okay, enough with your speculation about people's intentions that *you do not know*; either cough up some documentation / mailing list logs, etc that explicitly show that Codeweavers/Wine Developers intentions are how you say (or rather, how you nastily present them)... that shows thaty they are "boycotting" and "using authority to harm others" or SFTU, It's that simple... Seriously! - You are literally just talking shit / slandering people... Next, stop rehashing this nonsense about what this patch doesn't solve -> It's not supposed to solve problems that it wasn't designed to solve -> it's supposed to solve the bottleneck of using Wineserver, with has to do with multithreading (or lack there of, not all of this hoopla coming out of your mouth about other things)...

Also, You are wrong about Wine dying soon. Very much, not likely to happen. It's used in Commercial products (by several companies, including in H/W) and a big part of CodeWeaver's business... Maybe you think it will be dead because of native gaming or something like that (i don't know) but that's pretty limited thinking, if that is the case.

also, the likely hood of the state_tracker being used on other platforms (other than linux) is about ZERO, portable or not (which i am not even convinced they aare, and no; therefore there would absolutely no reason for these developers to add the functionality in Wine - i won't take your word for it. citations, or don't bother talking about it anymore). And as you pointed out - It would be needed to added to all of the GFX driver's on each platform. <so, yeah, as of now - it's non-portable, other than in theory>... and again, ithasn't gone through rigorous testing, nor the review process, nor would anyone who pays any attention to, or is aware how Wine development works, would actually expect that it would be merged...

First, actions=intentions, i am not fantasizing anything. Second i said that Wine's ToGLSL emulation will be gone, not Wine it self. Third this is not a forum for other platforms, but for free code. Fourth, it's not if they support it, it is not in their hands, the problem is the war against it and in collaboration with jokers from Chronos(Nvidia).

[artivision]

No, not a CodeWeavers guy, although I do interact with some of them and know a few wine developers, as well.... Okay, enough with your speculation about people's intentions that *you do not know*; either cough up some documentation / mailing list logs, etc that explicitly show that Codeweavers/Wine Developers intentions are how you say (or rather, how you nastily present them)... that shows thaty they are "boycotting" and "using authority to harm others" or SFTU, It's that simple... Seriously! - You are literally just talking shit / slandering people... Next, stop rehashing this nonsense about what this patch doesn't solve -> It's not supposed to solve problems that it wasn't designed to solve -> it's supposed to solve the bottleneck of using Wineserver, with has to do with multithreading (or lack there of, not all of this hoopla coming out of your mouth about other things)...

Also, You are wrong about Wine dying soon. Very much, not likely to happen. It's used in Commercial products (by several companies, including in H/W) and a big part of CodeWeaver's business... Maybe you think it will be dead because of native gaming or something like that (i don't know) but that's pretty limited thinking, if that is the case.

also, the likely hood of the state_tracker being used on other platforms (other than linux) is about ZERO, portable or not (which i am not even convinced they aare, and no; therefore there would absolutely no reason for these developers to add the functionality in Wine - i won't take your word for it. citations, or don't bother talking about it anymore). And as you pointed out - It would be needed to added to all of the GFX driver's on each platform. <so, yeah, as of now - it's non-portable, other than in theory>... and again, ithasn't gone through rigorous testing, nor the review process, nor would anyone who pays any attention to, or is aware how Wine development works, would actually expect that it would be merged...

State tracker= Portable library: http://www.phoronix.com/scan.php?pag...3d_d3d11&num=1

[ninez]

First, actions=intentions, i am not fantasizing anything. Second i said that Wine's ToGLSL emulation will be gone, not Wine it self. Third this is not a forum for other platforms, but for free code. Fourth, it's not if they support it, it is not in their hands, the problem is the war against it and in collaboration with jokers from Chronos(Nvidia).

You do not know their intentions, you only know that as of "right now" those patches haven't been accepted, nor can you predict what the future holds with 100% accuracy. (ie: you can't see the future). So no, you are not privy to knowing these people's motivations - only your own speculations based on limited information. That's it... So yes, You are living in a fantasy world, where anything that you make up in your head becomes fact. (but only in your head!)..

State tracker= Portable library: http://www.phoronix.com/scan.php?pag...3d_d3d11&num=1

Portable "in theory" only. that's all... The particualr state_tracker you are whining about isn't implemented anywhere else (multiplatform), and likely wont be, either.

[stefandoesinger]

Regarding the mesa d3d state tracker: http://lists.freedesktop.org/archive...ly/042185.html

Particularly:

Any credible long term solution would either need to work with
everything from ddraw to d3d11, or at least be capable of being made
to work for those. Note also that there are applications that mix e.g.
ddraw and d3d9, or ddraw and OpenGL. Those all need to work as well.

[artivision]

You do not know their intentions, you only know that as of "right now" those patches haven't been accepted, nor can you predict what the future holds with 100% accuracy. (ie: you can't see the future). So no, you are not privy to knowing these people's motivations - only your own speculations based on limited information. That's it... So yes, You are living in a fantasy world, where anything that you make up in your head becomes fact. (but only in your head!)..



Portable "in theory" only. that's all... The particualr state_tracker you are whining about isn't implemented anywhere else (multiplatform), and likely wont be, either.

Look at the code and not my comments. You just need to write a patch for the state tracker in order to speak with the OpenGL interface of the vendor. As it speaks now with Gallium OpenGL. More work is needed to have an emulator, and it is also needs vendor specific work (many different OGL implementations).

[bridgman]

Look at the code and not my comments. You just need to write a patch for the state tracker in order to speak with the OpenGL interface of the vendor. As it speaks now with Gallium OpenGL. More work is needed to have an emulator, and it is also needs vendor specific work (many different OGL implementations).

State trackers talk to Gallium3D pipe and winsys drivers, not to OpenGL. The OpenGL API code *is* a state tracker.

[artivision]

State trackers talk to Gallium3D pipe and winsys drivers, not to OpenGL. The OpenGL API code *is* a state tracker.

Both OGL3.3 and D3D9 state trackers speak to Gallium3D. Then Gallium represents shaders to the main synthesizer as lines, triangles and textures. I said that the D3D9 state tracker can speak to Catalyst via a patch, targeting the place where libogl32.dll does connect. My point is that we can make a Gallium driver that can speak to Catalyst via OGL, and make Catalyst work with the D3D9 state tracker. Then we don't need that because MESA is fast, near Catalyst and faster per clock against Nvidia.

[Dukenukemx]

Portable "in theory" only. that's all... The particualr state_tracker you are whining about isn't implemented anywhere else (multiplatform), and likely wont be, either.

What would be the problem if the state tracker were to only be for Linux? I don't understand am I missing something important?

[bridgman]

Both OGL3.3 and D3D9 state trackers speak to Gallium3D. Then Gallium represents shaders to the main synthesizer as lines, triangles and textures.

The shaders are represented as shaders in TGSI (which the pipe driver compiles to hardware instructions), not as lines/triangles/textures. Triangle vertices get processed by the vertex shaders then reassembled into triangles, the triangle is broken down into pixels, then an instance of the pixel shader runs for each pixel and generates an output using texture samples etc...

I said that the D3D9 state tracker can speak to Catalyst via a patch, targeting the place where libogl32.dll does connect. My point is that we can make a Gallium driver that can speak to Catalyst via OGL, and make Catalyst work with the D3D9 state tracker. Then we don't need that because MESA is fast, near Catalyst and faster per clock against Nvidia.

Are you talking about converting to the *inputs* of an OpenGL driver ? If so, isn't that basically what Wine does today ?

[artivision]

The shaders are represented as shaders in TGSI (which the pipe driver compiles to hardware instructions), not as lines/triangles/textures. Triangle vertices get processed by the vertex shaders then reassembled into triangles, the triangle is broken down into pixels, then an instance of the pixel shader runs for each pixel and generates an output using texture samples etc...



Are you talking about converting to the *inputs* of an OpenGL driver ? If so, isn't that basically what Wine does today ?

No Mr Bridgman, no. There are at least three ways to be portable:

1) We can patch D3D_ST to work with closed drivers instead of Gallium. You can make the patch yourself.

2) You can connect Gallium and closed drivers via a driver that speaks with OGL or OCL. You don't convert anything, you do it like a compute shader. Lets assume that i make an OCL compute shader with circles and spheres instead of triangles and lines. A compute shader does have the shader it self --and-- the rules to interact, wile a normal shader hes only the first. This way a compute shader adds new programs to the state tracker, or you can say that is an addon state tracker by it self. So we don't convert to OGL, the d3d9_st works by its own rules, with equal rights as your driver it self.

3) You can have good open drivers and the closed drivers, installed in any system at the same time, and you can switch without system restart. So you don't need to connect the d3d9_st with closed drivers.

Extra) Wine must be compiled for this, and we must have an option with a simple tick, if we want the d3d9_st or GLSL or WineD3D and GLSL off.

Final) I'm sorry if i showed disrespect to CodeWeavers people, it was not my intention. I just want Wine to implement other ideas to. If they don't want to work for this new thing it is their right. But it is not their right to exclude it from main Wine.