[virglrenderer-devel] [PATCH 6/6] renderer: add shader_storage_buffer_object support. (v2)

[Dave Airlie]

On 19 July 2018 at 05:41, Erik Faye-Lund <erik.faye-lund at collabora.com> wrote:
> On 18. juli 2018 19:58, Dave Airlie wrote:
>>
>> From: Dave Airlie <airlied at redhat.com>
>>
>> This pulls the code out from the gles31 development,
>> and modifies the caps to support two different limits
>>
>> (so far I've only found fs/cs vs everyone else limits differ)
>>
>> v2: fix buffer creation paths, limit maximums, handle indirect
>> (don't pass -1 into gl funcs when we don't need to).
>>
>> Co-authors: Gurchetan Singh <gurchetansingh at chromium.org>
>> ---
>>   src/virgl_hw.h       |   1 +
>>   src/virgl_protocol.h |  10 +++++
>>   src/vrend_decode.c   |  33 ++++++++++++++++
>>   src/vrend_renderer.c | 107
>> ++++++++++++++++++++++++++++++++++++++++++++++++++-
>>   src/vrend_renderer.h |   6 +++
>>   5 files changed, 155 insertions(+), 2 deletions(-)
>>
>> diff --git a/src/virgl_hw.h b/src/virgl_hw.h
>> index cd828ed..a85a14d 100644
>> --- a/src/virgl_hw.h
>> +++ b/src/virgl_hw.h
>> @@ -307,6 +307,7 @@ struct virgl_caps_v2 {
>>           uint32_t capability_bits;
>>           uint32_t sample_locations[8];
>>           uint32_t max_vertex_attrib_stride;
>> +        uint32_t shader_storage_buffer_object_maximums; /* 0:15 bits for
>> FS/CS; 16:31 bits for all other stages */
>
> Is it *really* worth the complexity to bit-pack this...?

I just didn't see the point of not doing it really, it's just an
internal protocol
detail and I was feeling like not wasting.

Dave.