[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