[PATCH 9/9] glamor: Use buffer_storage

Eric Anholt eric at anholt.net
Mon Mar 10 13:09:35 PDT 2014


Markus Wick <markus at selfnet.de> writes:

> Am 2014-03-09 05:07, schrieb Eric Anholt:

>> diff --git a/glamor/glamor_vbo.c b/glamor/glamor_vbo.c
>> index be2c2af..f736cbe 100644
>> --- a/glamor/glamor_vbo.c
>> +++ b/glamor/glamor_vbo.c
>> @@ -52,7 +52,49 @@ glamor_get_vbo_space(ScreenPtr screen, unsigned
>> size, char **vbo_offset)
>> 
>>      glBindBuffer(GL_ARRAY_BUFFER, glamor_priv->vbo);
>> 
>> -    if (glamor_priv->gl_flavor == GLAMOR_GL_DESKTOP) {
>> +    if (glamor_priv->has_buffer_storage) {
>> +        if (glamor_priv->vbo_size < glamor_priv->vbo_offset + size) {
>> +            if (glamor_priv->vbo_size)
>> +                glUnmapBuffer(GL_ARRAY_BUFFER);
>> +
>> +            if (size > glamor_priv->vbo_size) {
>> +                glamor_priv->vbo_size = MAX(GLAMOR_VBO_SIZE, size);
>> +
>> +                /* We aren't allowed to resize glBufferStorage()
>> +                 * buffers, so we need to gen a new one.
>> +                 */
>> +                glDeleteBuffers(1, &glamor_priv->vbo);
>> +                glGenBuffers(1, &glamor_priv->vbo);
>> +                glBindBuffer(GL_ARRAY_BUFFER, glamor_priv->vbo);
>> +
>> +                assert(glGetError() == GL_NO_ERROR);
>
> On release builds, glGetError won't be called and so this won't clear 
> the gl error log. So we'll fall back to the mbr code because of any gl 
> error somewhere in glamor.

Yeah, I think that's fine -- you shouldn't have any errors, anyway.

>> +                glBufferStorage(GL_ARRAY_BUFFER, 
>> glamor_priv->vbo_size, NULL,
>> +                                GL_MAP_WRITE_BIT |
>> +                                GL_MAP_PERSISTENT_BIT |
>> +                                GL_MAP_COHERENT_BIT);
>> +
>> +                if (glGetError() != GL_NO_ERROR) {
>> +                    /* If the driver failed our coherent mapping, fall
>> +                     * back to the ARB_mbr path.
>> +                     */
>> +                    glamor_priv->has_buffer_storage = false;
>> +                    glamor_priv->vbo_size = 0;
>
> glamor_put_context(glamor_priv);

Fixed.

> Which kind of error do you expect for a driver which isn't able to map 
> coherent? I've only found a GL_OUT_OF_MEMORY, but this will invalidate 
> the complete gl state. So I guess there is no legal way to support 
> arb_buffer_storage without coherent mapping at all.

I wonder if the caller is supposed to expect GL_OOM from this path and
assume that the context isn't totally trashed like the general GL_OOM
case.

So far, it looks like we're going to just always support COHERENT in
Mesa.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 818 bytes
Desc: not available
URL: <http://lists.x.org/archives/xorg-devel/attachments/20140310/915dc501/attachment.pgp>


More information about the xorg-devel mailing list