[Mesa-dev] Potential spec change request for EXT_buffer_storage

Ilia Mirkin imirkin at alum.mit.edu
Mon Nov 9 16:29:02 PST 2015


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).

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


More information about the mesa-dev mailing list