On Fri, Jun 6, 2008 at 10:47 AM, Younes Manton <[EMAIL PROTECTED]> wrote: > I think this would be a good time to speak up. My GSoC project > involves writing a state tracker for XvMC, aside from the mesa state > tracker I understand this is the only other public state tracker > around. I don't have any complaints about the current gallium > interface, but maybe someone could elaborate on what they have in mind > as far as changes go, even if it's preliminary. > > One thing I've noticed about about winsys is that from my > understanding, the state tracker is supposed to be OS and driver > independent,
The conclusion we're reaching is that while the bulk of the state tracker is OS independent (like current mesa state tracker is), there is a small part which will have some OS dependency (the part that will talk to DRI, GLX, WGL, etc.) > but for XvMC and VAAPI the following situation exists: > both are passed the drawable that will get rendered to late (after > creation), and that forces me to pass the drawable to the winsys > throught the state tracker as winsys->flush_frontbuffer(.., ..., > drawable) when it seems that last param is intended for > pipe_context->priv. > Not sure what the intention behind the priv member is, so maybe this > might be a bad idea when I target a HW driver instead of softpipe. We are also reaching the conclusion that the os-dependent part of the state tracker generally needs a special interface between the winsys. That At any rate it is impossible at the moment to guess how these changes will exactly turn out to be. So my suggestion is keep doing as you've been doing, and then this happens just make the similar move. I'm pretty sure that whatever works best for the existing state trackers should also works for your state tracker, but we can take a look at your code and ensure it does. > As an aside, is there any preferred directory structure people would > like to see for state trackers? Right now I'm using Nouveau's gallium > but this isn't necessarily nouveau specific and may find a home > elsewhere in the future. I'll be putting things in > gallium/state_trackers/g3dvl (g3dvl being gallium3d video layer) with > the following structure: > > src/ > libXvMC/ > tests/ > libVAAPI/ > tests/ > vl/ > tests/ > winsys/ > > vl/ is where the state tracker stuff is, although since VAAPI and XvMC > are somewhat similar (especially for mpeg2) I'm hoping to use the same > state tracker. For that reason things don't look like they do in the > mesa state tracker, I don't use XvMC types in the state tracker and > don't necessarily map 1:1 with XvMC functions. Directory structure is not entirely consensual. But the general existing principles are: - standalone libraries (no gallium dependency) in src/ - gallium auxiliary libraries (gallium dependency) in src/gallium/auxiliary/ - in lack of better place, state trackers in src/gallium/state_trackers/ - pipe drivers in src/gallium/drivers/ - winsys in src/gallium/winsys/ So according to that above, your tree would be separated and go into - src/libXvMC/ - src/libVAAPI/ - src/gallium/state_trackers/vl - src/gallium/winsys/vl But I wouldn't worry too much about this. Especially if it would affect your productivity. We can always discuss this again if/when merging. (Another option is having state trackers out of the gallium source tree. We have done it, and it is nice because avoids merges back-n-forth, but still didn't wrote any howto instructions on this regard.) BTW, do you have your code available somewhere? Jose ------------------------------------------------------------------------- Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php -- _______________________________________________ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
