Clarification about glTexSubImage2D on legacy-driver

[longo92]

Hi,
A question about glTexSubImage2D implementation:
Is it possible that the raspberry pi 0 gpu legacy driver implementation performs a copy only of the pointer data (instead of an entire copy)?
It seems reasonable since the memory is unified.

Thanks,
Alessandro

[Paeryn]

Hi,
A question about glTexSubImage2D implementation:
Is it possible that the raspberry pi 0 gpu legacy driver implementation performs a copy only of the pointer data (instead of an entire copy)?
It seems reasonable since the memory is unified.

Thanks,
Alessandro

I can't see any way of being able to get away with not copying the data. The physical memory may be unified but the VC4 texture units don't go through an MMU, think what would happen if Linux swapped the memory for your image out.

Using gTexSubImage suggests that you are copying the data into part of a larger texture, the texture needs to be one complete image, having a random rectangle of the texture stored separately to the rest in a random location would be a nightmare.

Then there's the fact that textures aren't generally stored in linear order due to that not being very friendly to the texture caches. Usually a texture is split into small tiles which snake around the texture in some manner (I think the RPi zigzags). This is so texels close to each other in coordinate space are more likely to be close in memory. Textures need to be fast to read regardless of rotation.

Finally, when you've submitted your image using glTexSubImage2D() you can safely free your image without affecting OpenGL's texture. OpenGL doesn't make any assumption that an application's memory is available to the graphics driver after a call returns (the texture memory could reside on a separate memory device not accessable by the cpu).

[Daniel Gessel]

Apple had an extension to allow this, but I don’t think anybody else has ever implemented it.

[longo92]

Thanks for you precious clarification.
BTW i think using this extension (supported by raspberry) you can achieve what i mean:
https://www.khronos.org/registry/OpenGL ... ternal.txt
For example you can decode a video outputting EGL images (wich are already on GPU memory) and than use the handler of that EGL image with that extension on OpenGL (see EGLImageTargetTexture2DOES), avoiding roundtrip on memory.

[Paeryn]

Yes you can use that, but your original post asked about doing a partial texture update with data from non-gpu allocated memory (which is what glTexSubImage2D() does). As far as I'm aware all EGL_images are gpu allocated and the texture will be the whole EGL_image.