First, that's the wrong memory barrier. The barrier is for how you intend to use the memory, not how it was written to.
I'd like to hide the latency by reading the data written by the previous frame dispatch.
This is a general flaw in OpenGL: targeted synchronization of such memory operations is not possible.
In Vulkan, you can be extremely specific ...
Operating systems cancel GPU program executions if they take too long. On Windows it is generally two seconds and on Linux it is five seconds most of the time, but it can vary.
This is to detect GPU programs that are stuck and cancel them. There are different methods to get around this timeout, but they all require admin/root privileges, which is not always ...
If silhouette is not important, you could bend the shading normal near edges.
Since it's a cube you can probably compute the normal procedurally in the shader based off of the uv. I.e. if uv is in range [0,0.1] or [0.9,1.0] start bending the normal towards horizontal.
If silhouette is important, drawing a rounded cube model with vertex normals would make ...
Operations between two vectors do not make sense unless both vectors are in the same space. So you must either transform the camera position into object space or transform the object position into camera space. I would suggest the latter, since you already likely have a matrix lying around for doing that for other reasons (lighting, etc).
Update the uniform and draw again.
auto tMVP = glm::translate(MVP, glm::vec3(1,0,0));
glUniformMatrix4fv(loc_MVP, 1, GL_FALSE, &tMVP);
tMVP = glm::translate(MVP, glm::vec3(2,0,0));
glUniformMatrix4fv(loc_MVP, 1, GL_FALSE, &MVP);
Using glTranslate would have done the exact same thing behind the scenes.
Solution: Check for the minimum x,y,z value for all points. Add these values multiplied by (-1) to all points in order to guarantee that all points are not negative. Then take the largest point and subtract with the minimum point (max and minimum x y z) in order to get a cube-like bound for the object.
Then divide this cube by an arbitrary size constant ...
There is no official list, but a community driven one. It is largely up to date:
As can be seen here AMD doesn't support the ARB_shading_language_include extension at the time I wrote this answer.
So it sounds like the main issue you're having is how to render something when all resources are already on the GPU. I would do it like this:
Create the destination RGB texture that's the proper width and height
Create an FBO
Set the texture created in step 1 as the output (write) texture of the FBO
Bind the NV12 texture to the texture unit you'll use in ...