Michel Dänzer <mic...@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...@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
_______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
