Open emersion opened 4 years ago
@mheyer32 is the contact on this spec now. These were pretty heavily "inspired" by the desktop specs. It's entirely possible that the enum was inadvertently copied from there.
@nvmheyer would be me with NVIDIA hat on :-)
This is certainly a mistake in the NV_pbo extension specs (which are in fact based off the desktop extension spec language) to use GL_STREAM_READ. The other example uses GL_STREAM_DRAW.
One could argue that the EXT_map_buffer_range extension should have introduced new usage hints as it allows reading back from buffers for the first time in GLES.
This should not be a huge problem, though. The buffer usage hints are not a good indicator of how a buffer is going to be used. The NVIDIA driver, for instance, will mostly ignore the hints and instead infer the optimal buffer storage from the actual usage.
This should not be a huge problem, though.
Ah, indeed, it seems like this is just a hint and that it doesn't constrain the actual usage. It's unfortunate that there's no "no hint" enum value.
Mesa also ignores the hint in this situation: https://gitlab.freedesktop.org/mesa/mesa/-/blob/e5339fe4a47c242693962c9f90bbab8b74935cba/src/mesa/state_tracker/st_cb_bufferobjects.c#L248
This is certainly a mistake in the NV_pbo extension specs
Should we somehow fix the examples?
One could argue that the EXT_map_buffer_range extension should have introduced new usage hints as it allows reading back from buffers for the first time in GLES.
Indeed. I'm not sure if/how we can fix that.
@nvmheyer Would you mind creating a PR to fix this minor issue? Thanks.
OpenGL ES 2.0 core only defines
GL_STREAM_WRITE
.NV_pixel_buffer_object
advertises that it allows "Asynchronous glReadPixels". The code examples useGL_STREAM_READ
. However including both<GLES2/gl2.h>
and<GLES2/gl2ext.h>
isn't enough to get access to this symbol necessary for creating a PBO that can be read from. No other GLES2 extension seems to define it.Is this an oversight?
cc @pow2clk