Re: gallium (was Re: radeon r6xx DRM...)
On Sat, Jun 7, 2008 at 12:07 AM, Younes Manton <[EMAIL PROTECTED]> wrote: > On Fri, Jun 6, 2008 at 6:12 AM, José Fonseca > <[EMAIL PROTECTED]> wrote: >> On Fri, Jun 6, 2008 at 10:47 AM, Younes Manton <[EMAIL PROTECTED]> wrote: >>> 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 > > Assuming I had my own repo you mean, or in mesa? I was referring to mesa. > I was planning on > using nouveau/mesa for the near future since Stephane is my mentor and > nouveau is what I plan to move on to once things are working with > softpipe, which would put libXvMC/ and libVAAPI/ alongside mesa/. > Don't know how others would feel about non mesa libs at the top of the > mesa tree, or if that's not a big deal. > >> BTW, do you have your code available somewhere? > > Uploaded a copy to http://www.bitblit.org/gsoc/g3dvl/src/ and will > soon commit current work to nouveau/mesa, > http://www.bitblit.org/gsoc/g3dvl/ is where I keep general info and > progress, etc. It's looking good. Looking forward to see the final outcome. 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
Re: gallium (was Re: radeon r6xx DRM...)
On Fri, Jun 6, 2008 at 6:12 AM, José Fonseca <[EMAIL PROTECTED]> wrote: > On Fri, Jun 6, 2008 at 10:47 AM, Younes Manton <[EMAIL PROTECTED]> wrote: >> 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 Assuming I had my own repo you mean, or in mesa? I was planning on using nouveau/mesa for the near future since Stephane is my mentor and nouveau is what I plan to move on to once things are working with softpipe, which would put libXvMC/ and libVAAPI/ alongside mesa/. Don't know how others would feel about non mesa libs at the top of the mesa tree, or if that's not a big deal. > BTW, do you have your code available somewhere? Uploaded a copy to http://www.bitblit.org/gsoc/g3dvl/src/ and will soon commit current work to nouveau/mesa, http://www.bitblit.org/gsoc/g3dvl/ is where I keep general info and progress, etc. - 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
Re: gallium (was Re: radeon r6xx DRM...)
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
Re: gallium (was Re: radeon r6xx DRM...)
On Wed, Jun 4, 2008 at 8:30 PM, Brian Paul <[EMAIL PROTECTED]> wrote: > Dave Airlie wrote: > > Stephane wrote: >>> Hi Brian, >>> >>> It seems like people are mostly concerned about gallium stability >>> right now. How stable wioll the interfaces be in the future ? Maybe if >>> you could tell us, that'd help others jump in. > > The gallium interfaces won't change radically, but we are looking at > some changes. 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. > In particular, the winsys stuff is kind of complicated and we're hoping > to simplify and re-organize it somewhat. "Winsys" basically includes > all the "stuff" needed to interface a portable gallium driver into the > non-portable window system and OS which hosts it. The dividing lines, > modularity and terminology(!) can be improved in that area. Jakob > Bornecrantz may be commiting some changes soon. One thing I've noticed about about winsys is that from my understanding, the state tracker is supposed to be OS and driver independent, 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. > Beyond that, there'll probably always be some evolutionary changes to > the gallium interfaces. It'll have to evolve just has Mesa has had to > evolve since we can't predict future needs. > > None of this should stop anyone from digging into gallium though. > > >> Even when it might make it to master, is it planned to land in master.. >> >> I would assume Mesa 8.0 or something. > > Gallium might ultimately wind up in its own repository as a stand-alone > project. Afterall, Gallium drivers could be used by APIs other than OpenGL. 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. - 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
Re: gallium (was Re: radeon r6xx DRM...)
On Jun 04, 08 18:30:56 -0600, Brian Paul wrote: > Gallium might ultimately wind up in its own repository as a stand-alone > project. Afterall, Gallium drivers could be used by APIs other than OpenGL. Yes, but the base project is called Mesa and not OpenGL. So that wouldn't exactly stop that ;-) > When either of those things happens a Mesa 8.0 release would probably be > appropriate. I haven't thought about a time frame yet, but the end of > the year might be a good goal. Sounds good. Especially as nobody really has to wait until then to dig into it. Matthias -- Matthias Hopf <[EMAIL PROTECTED]> ____ __ Maxfeldstr. 5 / 90409 Nuernberg (_ | | (_ |__ [EMAIL PROTECTED] Phone +49-911-74053-715 __) |_| __) |__ R & D www.mshopf.de - 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
Re: gallium (was Re: radeon r6xx DRM...)
> > Gallium might ultimately wind up in its own repository as a stand-alone > project. Afterall, Gallium drivers could be used by APIs other than OpenGL. The question is mainly from a distro point of view what do we need to ship a gallium driver. The current method would mean we need a Mesa tree for normal DRI drivers and a gallium-mesa tree for gallium based drivers. This isn't brutal but I'd hate to spend a lot of time on the setup phase just to find the target moved. So if gallium is in a separate project will it need parts of Mesa to build. If it needs parts of mesa to build does it make sense in another project. Will the gallium/mesa interface move. so we end up having to provide synced version in any case, in which case why have different trees. Dave. - 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
