Re: OSMesa and Gallium/LLVM

On 09/27/2012 12:23 AM, [email protected] wrote:
> Hallo,
>
> and Thanks for the quick response!
>
> On 26.09.2012 16:22, Brian Paul - [email protected] wrote:
>> On 09/26/2012 05:18 AM, [email protected] wrote:
>>> Hallo!
>>>
>>> I'd just like to ask if it is possible to use llvmpipe with OSMesa as
>>> target.
>>
>> No, we'd basically need to write an OSMesa "state tracker" for
>> gallium. It's on my long-term to-do list, but pretty low priority.
>
> How much effort do you think this would take? Doesn't it mean just to
> replace the access operations to the X11 pixel store?

No, it roughly means taking the src/mesa/drivers/osmesa/osmesa.c code, 
moving it to src/gallium/state_trackers/osmesa/ and rewriting it to 
work with Gallium.


>>> Any other offscreen rendering solution would be fine too, as
>>> long as it doesn't need an X Server (That's why PBuffers are not an
>>> option).
>>
>> In terms of core OpenGL, you could use framebuffer objects to do
>> off-screen rendering. But you'll still need some method of creating
>> a rendering context, etc. Since you don't have an X server, GLX is
>> out. EGL is the next logical choice but I don't think anyone's
>> implemented a "dumb" EGL which doesn't use the window system at all.
>
> I see...
>
>> I'm afraid I don't know of any simple solution to your problem at
>
> This is sad news because there are two reasons for me to prefer the
> LLVM solution:
>
> - I'ts supposed to be much faster.
> - There seems to be a bug with the LOD selection of mipmaps when using
> shaders (I haven't found any entries in bugzilla, may be I should
> file one myself?).

Sure, but I have a feeling this problem can't easily be fixed because 
of the way that fragment shaders are executed for swrast (there's no 
neighboring fragment information to properly compute texcoord 
derivatives).

-Brian