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
