[Mesa-dev] [PATCH] mesa/bufferobj: fix atomic offset/size get

Tapani Pälli tapani.palli at intel.com
Fri Oct 13 03:37:02 UTC 2017



On 10/12/2017 11:14 PM, Dave Airlie wrote:
> On 12 October 2017 at 18:22, Tapani Pälli <tapani.palli at intel.com> wrote:
>>
>>
>> On 10/12/2017 11:14 AM, Dave Airlie wrote:
>>>
>>>
>>> On 12 Oct. 2017 15:40, "Tapani Pälli" <tapani.palli at intel.com
>>> <mailto:tapani.palli at intel.com>> wrote:
>>>
>>>
>>>
>>>      On 10/12/2017 02:34 AM, Dave Airlie wrote:
>>>
>>>          From: Dave Airlie <airlied at redhat.com <mailto:airlied at redhat.com>>
>>>
>>>          When I realigned the bufferobj code, I didn't see the getters
>>>          were different, realign the getters to work the same as ssbo.
>>>
>>>
>>>      Alternatively you could set these values as 0 in
>>>      bind_buffer_base_atomic_buffer()? Not sure if it's any better but
>>>      then value would match internally what it has been before these
>>> changes.
>>>
>>>
>>> Before these changes the ssbo and atomic code was gratuitously different,
>>> this is just the last piece of making them consistent.
>>
>>
>> Right .. what I mean is that before the refactoring Size and Offset values
>> in the structure were stored as 0, now they are stored as -1 even though
>> here we return different value. I haven't checked if anything in Mesa would
>> assume 0 though .. so feel free to ignore my ramblings :) I just wanted to
>> note this because I tried to fix this and it following change fixes the bug
>> as well:
>>
> 
> For atomics that is true, but for ssbo it was false. The idea of refactoring it
> was to align all the code to be same for both, since there is no reason for
> differences. Your change would reintroduce differences where none are needed.
> 
> My change to get.c aligns the gets
> for
> GL_ATOMIC_COUNTER_BUFFER_START
> GL_ATOMIC_COUNTER_BUFFER_SIZE
> with the ones above
> for
> GL_SHADER_STORAGE_BUFFER_START
> GL_SHADER_STORAGE_BUFFER_SIZE
> 
> So the code is consistent across both types of buffer.
> 

Right, got it! Thanks;

// Tapani


More information about the mesa-dev mailing list