[Mesa-dev] vbo code and flush explicit mapping

Brian Paul brianp at vmware.com
Tue Apr 30 08:17:00 PDT 2013


On 04/30/2013 09:03 AM, Jose Fonseca wrote:
> ----- Original Message -----
>> On Mon, Apr 29, 2013 at 2:52 PM, Dave Airlie<airlied at gmail.com>  wrote:
>>> I've been playing with a gallium driver, and started looking at some
>>> wierd gears behaviour,
>>>
>>> The vbo code maps the buffer with GL_MAP_FLUSH_EXPLICIT_BIT which to
>>> me requires that at some point
>>> we call ctx->Driver.FlushMappedBufferRange. Now the code attempts to
>>> call it in vbo_exec_vtx_unmap
>>> but from what I can see the length is always 0 in there and so we
>>> never get called.
>>>
>>> GLsizeiptr length = (exec->vtx.buffer_ptr - exec->vtx.buffer_map) *
>>> sizeof(float);
>>>
>>> but I can not see buffer_ptr != buffer_map when we hit this code, I'm
>>> a bit lost at this point, maybe someone else might know more.
>>
>> Okay maybe I'm missing something, I'm just tracing gears with softpipe
>> and realised the map/unmap
>> pairs occur due to the Material calls but they don't actually seem to
>> modify the VBOs.
>
> That's weird.
>
> I thought that material changes would just translate to constant buffer updates.
>
> It looks like we replace the glBegin .. glEnd with VBOs, but we still translate Material calls literally.
>
> Now that no Mesa driver handles fixed function directly, we could probably simplify some of these things.
>

glMaterial is complicated.  It's handled differently depending on 
whether it's called inside or outside glBegin/End or in a display list.

Even though I've been working in the VBO code lately, it would take me 
a while to re-learn how glMaterial is handled.

-Brian



More information about the mesa-dev mailing list