The Status Of Gallium3D Drivers, State Trackers

[Med_]

You're reading the table wrong: It doesn't show the completion state of the state-trackers, but it shows the ability of the drivers to run the state-trackers. So there's really just one state-tracker for each functionality (which afaik are more or less complete), but the drivers are not yet able to run them.

Ah thanks, i think i see what you mean. So for instance an incomplete pipe driver might be able to run only some ST for instance due to some missing implementations?

[MostAwesomeDude]

Anything that Wine has done regarding w32api implementation has been more or less accepted as legal. Most of the ReactOS code is also okay.

Ah thanks, i think i see what you mean. So for instance an incomplete pipe driver might be able to run only some ST for instance due to some missing implementations?

Pretty much. This is also going back to the idea of conformance tests. State trackers should demand precise or predictable results from pipes, so if a pipe has a small bug that only affects one state tracker, we shouldn't mark the entire pipe as broken. This is similar to how we have a table of games on r300; the table shows that occasionally certain games might have defects, but it doesn't mean that the entire driver is bad.

[wien]

All signs point to Tungsten/VMWare having an internal DirectDraw/Direct3D state tracker already, but they haven't confirmed this.

Even if they do, it wouldn't be of much use for Linux/Wine. Windows D3D drivers don't implement the entire API like Windows OpenGL drivers do. There's a huge chunk of the D3D API that's written by Microsoft and then layered on top of a simpler API the drivers implement. You'd need to reimplement all that code as well before you'd have a complete Direct3D state tracker usable on Linux, and at that point it's probably easier to just make a native D3D state tracker.

[NeoBrain]

You don't believe getting rid of an emulation level would yield higher performance? (as in, you wouldn't have to do D3D->OpenGL conversion anymore)

I do believe that native D3D support within drivers would speed up things (uhm, that's what I acutally said).

It's mostly a matter on whether Wine developers want to keep using OpenGL or not for D3D.

That would mean we'd replace a quite well tested and optimized (and pretty well working) framework with a framework which would be damn buggy for at least two years and won't be supported properly by _any_ driver within the same time period. That's why we'd need to keep the old code for compatibility and even just making it possible to switch between redirecting OpenGL->D3D and native D3D support would be such an invasive change that half of today's supported applications would break due to some regressions...

Right, so we can't go for the likely better implementation (not using OpenGL) just because closed drivers aren't going to support that (they only want to use OpenGL)?

Only because OSS drivers would get a 20% boost in performance (which is unlikely) that doesn't mean it would work better than the closed driver. Note that I would not expect any speed improvement on the OSS side since the D3D driver simply wouldn't be on pair with the OGL one performance-wise. The OSS OpenGL drivers have been in development for so many years now (that is: optimized) that a D3D driver would need at least 5 years to catch up.

Since when did Linux userland development start depending on the whim of proprietary driver coders? This is as close as native D3D as you can get.

It's not that we depended on what the ATI devs are willing to do, but it's a matter of fact that they are pretty unlikely to implement it (remember they mostly implement stuff the workstation market uses). BUT there are Wine users who do not want to pay 200 € for their brand new X4950 to use the OSS drivers and only get 30% of the binary driver's performance (uhm, seeing that no OSS driver can run SM2 games, that should be the vast majority), so if we simply "dropped" support for binary drivers we'd lose like 80% of our users

[nanonyme]

Did I say somewhere I said things need to be dropped now in favour of something else? The development timeline will probably be anyway from months to years, no end-user would be seeing any differences for a long time regardless of what they did... And note, the biggest benefits of D3D over G3D aren't in speed but in that like WineHQ's wiki says, you currently need a much newer card with the OpenGL emulation than with native D3D because the emulation is a tad lossy.

[nanonyme]

You'd need to reimplement all that code as well before you'd have a complete Direct3D state tracker usable on Linux, and at that point it's probably easier to just make a native D3D state tracker.

Gallium3D D3D would pretty much be a native D3D state tracker...

[wien]

Gallium3D D3D would pretty much be a native D3D state tracker...

Not the one VMWare (probably) already have, which was my point.

[nanonyme]

Not the one VMWare (probably) already have, which was my point.

Well, no one said the state tracker couldn't be used also for other use than just for VM's, did they? It's probably just a new API for userspace applications to use. If it's close to the real D3D API, shouldn't be impossible to have eg have a fork of Wine that maps D3D functions against functions in Gallium3D D3D API. There'd be guaranteed to be equivalents for every function then.
EDIT: Edit functionality sucks, I think it has actually increases the amount of typos since you know you can correct them and don't pay as much attention.

[wien]

Well, no one said the state tracker couldn't be used also for other use than just for VM's, did they?

No, but this has nothing to do with VMs. It has to do with the Windows driver model.

It's probably just a new API for userspace applications to use. If it's close to the real D3D API, shouldn't be impossible to have eg have a fork of Wine that maps D3D functions against functions in Gallium3D D3D API. There'd be guaranteed to be equivalents for every function then.

Look, Windows Direct3D applications use the Direct3D API. Windows Direct3D drivers, and thus the probable Gallium D3D state tracker, implement the DDI API. Between these two there's a whole mess of stuff, the Direct3D runtime, that's written by Microsoft and that houses among other things the HLSL compiler. This is a lot of code.

Unless Wine's Direct3D layer also uses an intermediate DDI that matches the one in Windows (and why would it?), the D3D state tracker VMware probably already have would be of little use as you wouldn't have the runtime. At that point it's probably easier to just map the entire Direct3D API on top of Gallium in a separate state tracker instead of trying to shoehorn DDI in there.

That's my point. Nothing more, nothing less.

[some-guy]

There could be a partial D3D state tracker as well, something that would take over the non-convertible parts, like HLSL