[Mesa-dev] Potential spec change request for EXT_buffer_storage

[Ian Romanick]

On 11/09/2015 04:29 PM, Ilia Mirkin wrote:
> On Mon, Nov 9, 2015 at 7:10 PM, Ian Romanick <idr at freedesktop.org> wrote:
>> On 11/04/2015 03:26 PM, Ryan Houdek wrote:
>>> I'm hoping to potentially convince about lowering the minimum
>>> requirement of EXT_buffer_storage from ES 3.1 to ES 3.0.
>>> The only thing that causes it to require ES 3.1 is glMemoryBarrier,
>>> which shouldn't really be a hard requirement since the extension can be
>>> used without it.
>>> This is also a similar situation with ARB_buffer_storage which Mesa
>>> currently exposes to all GL versions even though it should require GL 4.2.
>>> I have my attempt at a change to the spec as follows. I've never tried
>>> changing a spec page before so it's a bit new to me.
>>
>> I think all of the drivers that support ARB_buffer_storage also support
>> ARB_texture_barrier.  At the very least I think you'd need to require
>> GL_MAP_CHOERENT_BIT with GL_MAP_PERSISTENT_BIT.
> 
> Not freedreno (and only very recently for i965). Although I guess it
> shouldn't be too hard to stick a gmem2mem step into the queue for such
> an occasion without interrupting the tiling.
> 
>> Also... Mesa is really close to getting OpenGL ES 3.1.  Are there any
>> drivers with which you want to use this extension that won't have GLES 3.1?
> 
> It'll be quite a while before freedreno supports GLES 3.1, and it's
> unclear to me that the a3xx hardware will even be capable of it
> (although it quite possibly may be).

The goal was that GLES 3.1 would be implementable on any hardware on
which vendors had shipped GLES 3.0.  Although wikipedia
(https://en.wikipedia.org/wiki/Adreno) thinks only A4xx can do GLES 3.1.
 Given that it also lists OpenCL 1.1 and DX 11.1 (although it does also
say only feature level 9_3 is supported), I think the hardware can do
it, but Qualcomm just didn't have customer demand to implement it.

Hmm... I guess whether the hardware is capable or not, freedreno may
never support it.  That means we should proceed with this.

I think the right approach will be to get things to match what we plan
to ship, then attach the patch to a bug in the Khronos public bugzilla.
 I can then follow-up with Daniel and the people who manage the registry
to get the changes through.  This is an EXT, so there's no voting or
committee debates necessary.

> I don't know how far we are from being able to reasonably drop
> freedreno into an android environment, but probably closer and more
> plausibly than other drivers (i.e. adreno hw is on devices you'd run
> android on... you could run android on your desktop pc too, but...
> less likely, and you'd have GL there).
> 
>   -ilia