[Mesa-dev] Direct3D 9 state tracker

[Jose Fonseca]

----- Original Message -----
> So, about two months ago I had the insane idea to pick up Joakim
> Sindholt's Direct3D 9 state tracker that he'd started about 3 years ago
> with the goal to make it run StarCraft 2 so I could finally play at a
> reasonable frame rate ...
> 
> With help from Joakim and advice from the wine developers, as well as
> wine's d3d9 tests, things went surprisingly smooth and my original goal
> has been achieved and surpassed, hence I thought I'd post a note here in
> case someone who doesn't yet know about it is interested in trying it out.
> 
> ... Now wait, didn't we have a D3D10/11 state tracker already that we
> kicked out because it was unmaintained and not really useful ?
> Yes, but there are a couple of differences to d3d1x:
> 
> - the original author has not vanished [yet] (Luca, if you can hear me:
> You cannot leave your children out to die like that !)
> - it's written in C instead of C++ and not relying on horrific multiple
> inheritance with templates hacks to make gcc generate COM-compatible
> vtables (and I'm still not sure if that actually worked)
> - gallium wasn't ready for D3D11, and still isn't (at least the pipe
> drivers aren't), but it is ready for D3D9, and all the features required
> from the pipe drivers are well tested via OpenGL
> - there are no motivating applications using Direct3D 10/11 yet (at
> least for me)
> - and most importantly, contrary to d3d1x, d3d9/st already actually
> works for real applications !
> 
> So far I've tried Skyrim, Civilization 5, Anno 1404 and StarCraft 2 on
> the nvc0 and r600g drivers, which work pretty well, at up to x2 the fps
> I get with wined3d (NOTE: no thorough benchmarking done yet).
> Civilization 4 works, too, but it still has a couple of (not too severe)
> rendering issues because I didn't pay much attention to the fixed
> function pipeline and its interaction with the earlier shader versions yet.
> 
> If people think it's a good idea to merge it, I'd clean up the few
> modifications I did to gallium, and, once they've been cleared, merge
> the state tracker itself.
> Unfortunately, for proper window system integration, a few modifications
> to wine are required (it used to run without them, but fully correct
> operation isn't possible like that).

My stance is the same I had with D3D10 state-tracker: 

- I haven't looked at the code yet, but in principle I don't oppose merging as long as it is maintained in a building and running state, in particular in face of interface changes [1].  That said, given the past track record, I suspect it won't survive if it remains an one-man-project.  

  That is, more than "to merge or not merge" issue, I'd focus on making this appealing to a wider audience.

- It seems to me that this would be more useful if the state tracker targeted not the D3D9 API, but the WDDM D3D9 DDI [2].  Targeting the DDI would allow, e.g., to share more code with rest of WINE (the API->DDI runtime layer); to conveniently switch between this Gallium implementation and the current D3D9 GL implementation; ReactOS could also use the runtime bits for native IHV driver support; people wanting to write native gallium Windows drivers could also use the state tracker as a starting point, and one might even be able to run this with Microsoft conformance tests on Windows to test/validate it.

  But as it stands now -- a D3D9 runtime drop-in replacement --, I really see no use outside WINE (and maybe not even that, if D3D11.x's history repeats.)


These are just my 2c.  I really have no vested interest in this: either way, I'm afraid that it is very unlikely that this ever becomes of direct use to me or my employer.  But I'd still prefer to see this succeed in some form, as I believe that Gallium ecosystem would be healthier with more state trackers out there supporting different APIs.


Jose


[1] For example, as we cleanup TGSI opcodes, I think we should refactor TGSI opcodes such that instead of being a messy superset GL ARB opcodes + D3D9 opcodes + D3D1x opcodes they become a leaner abstraction of these APIs, because there are way more pipe drivers than state trackers (and that's an unavoidable trend, as APIs tend to stick a round much longer than particular pieces of HW), so we should weigh on making pipe driver implementers' lives easier.


[2] http://msdn.microsoft.com/en-us/library/windows/hardware/ff552927.aspx