> A way to unblock this would be to split thed3d1x state tracker in two parts: > the runtime, and the client driver. As Keith also suggested. > > The client driver could be used on Windows -- precisely as the DDK and WDK > are intended. > > The runtime part could be re-implemented from scratch by WINE or REACTOS, > using their standard development practices.
This is possible, but in my opinion, it would risk creating bigger concerns. Right now we implement the public COM API published by Microsoft, but do not attempt to mimic any internal or undocumented details of the Microsoft implementation in any way. Implementing the COM API over the DDI API would cause the code to extensively rely on WDK interfaces and create an architecture identical to the one used by Microsoft. In my opinion, this would greatly increase the ability of anyone to claim it violates Microsoft intellectual propertly. On the technical side, I understand that such a state tracker is also important to have. Regardless of whether we have a COM->Gallium or COM->DDI->Gallium, approach a UMDDI->Gallium state tracker is necessary. Hence, I think the best route would be to start by writing an UMDDI state tracker. The shader translation code can be fully shared, and the implementation of the COM API can be probably adapted or used for reference when implementing the UMDDI API Once this is done, one can better decide whether to keep the current COM->Gallium direct translation layer, or change my code into a COM->DDI layer. _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
