On Tue, 2013-07-23 at 08:39 +1000, Dave Airlie wrote: > On Tue, Jul 23, 2013 at 8:21 AM, Marek Olšák <mar...@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 _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
