Originally posted by Zhick
View Post
Announcement
Collapse
No announcement yet.
The Status Of Gallium3D Drivers, State Trackers
Collapse
X
-
Anything that Wine has done regarding w32api implementation has been more or less accepted as legal. Most of the ReactOS code is also okay.
Originally posted by Med_ View PostAh 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?
Comment
-
Originally posted by MostAwesomeDude View PostAll signs point to Tungsten/VMWare having an internal DirectDraw/Direct3D state tracker already, but they haven't confirmed this.
Comment
-
Originally posted by nanonyme View PostYou 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)
Originally posted by nanonyme View PostIt's mostly a matter on whether Wine developers want to keep using OpenGL or not for D3D.
Originally posted by nanonyme View PostRight, 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)?
Originally posted by nanonyme View PostSince 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.
Comment
-
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.
Comment
-
Originally posted by wien View PostYou'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.
Comment
-
Originally posted by wien View PostNot the one VMWare (probably) already have, which was my point.
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.
Comment
-
Originally posted by nanonyme View PostWell, no one said the state tracker couldn't be used also for other use than just for VM's, did they?
Originally posted by nanonyme View PostIt'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.
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.Last edited by wien; 16 August 2009, 12:20 PM.
Comment
Comment