[Mesa-dev] Direct3D 9 state tracker

[Joakim Sindholt]

On Tue, 2013-07-23 at 08:39 +1000, Dave Airlie wrote:
> On Tue, Jul 23, 2013 at 8:21 AM, Marek Olšák <maraeo at gmail.com> wrote:
> > I think this is radically different from d3d1x, as it already can be
> > used to play games from Blizzard, Bethesda, and other companies
> > according to Christoph. I don't think this is much about what's best
> > for Wine, because Wine has to work on multiple operating
> > systems/drivers anyway. I think this is about what's best for the open
> > source graphics drivers, and skipping the OpenGL middle layer is
> > certainly not a bad idea.
> >
> > I think Wine should allow drivers, both open and closed, to implement
> > d3d9 by themselves. In any case, wined3d can be used as a fallback if
> > no compatible d3d9 driver has been found, which has already been
> > implemented by Christoph if I understood him correctly.
> > I see no problem with this. Let's merge the Wine patches, then the
> > d3d9 state tracker, then let the community test it and report bugs.
> > Once we're comfortable with it, we can enable building the d3d9
> > gallium drivers by default and the user base should skyrocket. Isn't
> > it a good plan?
> >
> 
> Totally, if we can find some way for wine to pick up the dll so
> distros can package it even better.
> 
> Like some sort of search path for /usr/lib64/dri/ or a look for
> winemesad3d.dll first then fallback to the wined3d.dll (or however
> this works).
> 
> Dave.

Hi, I designed the interface :)

I actually had this in mind when designing it, and also the possibility
of wine's internals changing. The way it currently works is by compiling
into a window-system-less library called libd3dadapter9.so, which
exports a single function called D3DAdapter9GetProc, which takes a
string identifying the subsystem (currently only "drm"). It gives you
back a const struct containing that particular subsystem's details and a
function pointer to create an ID3DAdapter9 (a custom COM interface). The
st itself makes use of COM interfaces implemented within the target
window system (wine) called ID3DPresent and ID3DPresentGroup. These talk
to the window system and facilitate displaying things on screen.
All these interfaces can be seen in include/d3dadapter/*.h.

Of course they're not finished yet, as they lack support for a few key
features like Get/ReleaseDC, Reset, having driver-buffer-only
swapchains, flipping in various different ways to avoid blits and the
like. Suffice to say it needs work. I would like it to work with the new
DRI3 interface and remain compatible with DRI2 (and whatever else we can
throw at it with maximum performance).

As to the coexistence with wined3d, yes, it does. It will only try this
if the right DWORD registry key is non-zero, the libd3dadapter9.so was
present at compile-time AND run-time, and an ID3DAdapter9 could both be
created and had pipe_* drivers present that loaded successfully; so in
that regard, it's rather pedantic. If any of the above requirements are
unmet it will seamlessly fall back to wined3d.

Hope this clarifies a few points,
- Joakim