Markus Wick <[email protected]> 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.
pgp0yIZm78Y0J.pgp
Description: PGP signature
_______________________________________________ [email protected]: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
