[Mesa-dev] multiple versions in version string

[tom fogal]

Michel Dänzer <michel at daenzer.net> writes:
> On Die, 2011-06-21 at 10:34 -0600, tom fogal wrote:=20
> > On 06/21/2011 10:23 AM, Michel D=C3=A4nzer wrote:
> > > On Die, 2011-06-21 at 10:10 -0600, tom fogal wrote:
> > >> On 06/21/2011 01:06 AM, Michel D=C3=A4nzer wrote:
> > >>> On Mon, 2011-06-20 at 13:46 -0600, tom fogal wrote:
> > >>>> Nathan Kidd<nathan-ml at spicycrypto.ca>   writes:
> > >>>>> On 11-06-20 02:55 PM, tom fogal wrote:
> > >>>>>> You are correct, rendering is indirect!
> > >>>>>
> > >>>>> Of course, for indirect rendering every glFoo() function call
> > >>>>> needs to be mapped to (GL)X protocol.  Protocol exists up to
> > >>>>> OpenGL 1.4.
> > >>>>
> > >>>> I can always fall back to OSMesa, I suppose :(
> > >>>
> > >>> Or a software rasterizer libGL / driver which uses direct
> > >>> rendering. Preferably using llvmpipe for performance.
> > >>
> > >> It was hidden in another part of the thread, but I actually
> > >> don't care (much) about performance, as this is for a regression
> > >> testing system.
> > >
> > > Then you have free choice between llvmpipe or just softpipe (can
> > > be chosen at runtime), or even classic swrast.
> >
> > Yep.  I have used swrast with great effect in the past.
> >
> > Gallium and OSMesa currently don't mix, though Brian has mentioned
> > once or twice that it wouldn't be /too/ hard to bring up.
>
> Does GLX indirect rendering 'mix' with OSMesa at all? If not, why are
> you bringing this up? :)

No; OSMesa stands in place of GLX, of course.

I mentioned they don't mix because you implied I could try using
llvmpipe or softpipe.  In reality, the only option for a standalone RTS
that needs GL2.0 is swrast/OSMesa.

> > > It should work fine with Xvfb or any other X server, using any
> > > kind of display connection.
> >
> > This thread started because Xvfb isn't offering what I need: GL
> > 2.0.
>
> Because you're using indirect rendering.

Yes.  That's the point, I /can't/ get direct rendering with Xvfb.

> > Xvfb is actually exactly the kind of thing I want, I just need GL 2
> > or appropriate extensions.
>
> And you can get that with a standalone software rasterizer libGL,
> which is why I brought it up.

Yes, but I have to build (+ maintain) OSMesa on all of my regression
testing machines.  It's an additional dependency.  I have to adjust all
my build/linking scripts to point at the custom-built OSMesa.  Some
machines have a /scratch for this, others I must do it in a $HOME,
others have the equivalent of /scratch but somewhere else; that is,
each machine needs customization.  When there are upgrades, something
occasionally breaks.  As my software stack grows, it becomes a larger
issue -- if we use a GL-based library, we have to compile a special
version of /that/ against our OSMesa, for example.  When there are bugs
(i.e. the TLS issue that I *still* haven't fully resolved) I have to
spend time in other projects to get them fixed.  I need to code up an
additional "create OSMesa context" code path in my software.

I do exactly the above for the regression testing system on another
project.  It eats time.  Such work is invisible to those who fund me
(though it does give me warm fuzzies.)  I was hoping to improve the
situation for this application.

If you were talking a non-OSMesa libGL, that's even worse: then I need
to manage multiple users' access to X servers.

-tom