Graphics Rendering with OpenGL ES - GDC 2006 presentations (PS3)

[Graham]

No probs!

I need to translate these acronyms from tutorial 7,

VBO = Vertex buffer objects?
FBO = frame buffer objects?
PBO = Pixel buffer objects?

Does vertex buffer objects suggest render to vertex buffer? Therefore improved vertex texturing?

in current desktop openGL the VBO extension is simply storing vertex data in graphics memory, it does not imply the ability to render to vertex data (well, last time I used VBO anyway ... FBO is, as far as I recall, is the basis of the new method of doing render to texture (I have yet to use that extension however, it was designed to replace P-buffers for render to texture, which are *utterly* terrible. Basically it's very similar to the DX model in terms of perf/features).
As for pixel buffer objects, I remember reading about them way back in the day as a 'omg a new feature' feature which never really got moving. I honestly can't remember exactly how they worked, they may have become the equivalent of memexport? Maybe it was an equivalent of VTF for pixel shader contants, but yeah I can't recall.

 

[j^aws]

Ignoring OpenGL (everybody does ;-) ), Aliasing vertex memory and render targets is trivial in the extreme on fixed hardware... cos memory is memory is memory, you could do it on Xbox (the original) if you felt like it...

Its almost impossible to stop it... how does the GPU know if your rendering into something you later call a vertex buffer, its just memory offsets to the GPU...

You know, for a second there, I thought you were about to break into a song!

I get what you're saying, I think... a 'buffer' is 'just' a memory resource to shaders whether they're running on SPUs, VSUs or PSUs. What wasn't clear was what could be 'inputs' and 'outputs' depending on 'where' the shader was running...

in current desktop openGL the VBO extension is simply storing vertex data in graphics memory, it does not imply the ability to render to vertex data (well, last time I used VBO anyway ...

Perhaps Ingenu was referring to an NV specific extension in OpenGL? Perhaps Ingenu or a dev could clarify?

FBO is, as far as I recall, is the basis of the new method of doing render to texture (I have yet to use that extension however, it was designed to replace P-buffers for render to texture, which are *utterly* terrible. Basically it's very similar to the DX model in terms of perf/features)...

Yeah, that's what I was thinking with FBOs...

As for pixel buffer objects, I remember reading about them way back in the day as a 'omg a new feature' feature which never really got moving. I honestly can't remember exactly how they worked, they may have become the equivalent of memexport? Maybe it was an equivalent of VTF for pixel shader contants, but yeah I can't recall.

A "memexport" equivalent would be interesting. Though I was suspecting that PBOs were a mechanism to allow the 'outputs' from vertex shaders, as 'inputs' to pixel/fragment shaders...?

 

[Rodéric]

Perhaps Ingenu was referring to an NV specific extension in OpenGL? Perhaps Ingenu or a dev could clarify?

I've not had time to implement that myself, but the idea is to render to PBO then use it as VBO.

A "memexport" equivalent would be interesting. Though I was suspecting that PBOs were a mechanism to allow the 'outputs' from vertex shaders, as 'inputs' to pixel/fragment shaders...?

Well PBO are rather powerfull you can use them for input &/| output.
They can be used for :
-Streaming texture updates
-Streaming draw pixels
-Asynchronous glReadPixels
-Render to vertex array
(Straight from the Spec Here.)

 

[j^aws]

I've not had time to implement that myself, but the idea is to render to PBO then use it as VBO.




Well PBO are rather powerfull you can use them for input &/| output.
They can be used for :
-Streaming texture updates
-Streaming draw pixels
-Asynchronous glReadPixels
-Render to vertex array
(Straight from the Spec Here.)

Thanks for the info.

Dave also mentioned this in his R520 article,

...Render to Vertex Buffer should be supportable by any DirectX9 (SM2.0 or 3.0) board, should the vendors choose to expose it. As pre-VS3.0 hardware does not have any vertex texture sampler support only one R2VB sampler can be specified, however with ATI's VS3.0 hardware the driver exposes up to five samplers and we believe that this could be equally supportable in NVIDIA's NV4x/G7x series...

http://www.beyond3d.com/reviews/ati/r520/index.php?p=02

...so it's not really surprising that R2VB is exposed via PSGL...

 

[Shifty Geezer]

A "memexport" equivalent would be interesting. Though I was suspecting that PBOs were a mechanism to allow the 'outputs' from vertex shaders, as 'inputs' to pixel/fragment shaders...?

If I've got this right, MemExport can arbitarily send data from any point in the shader to memory, whereas ordinarily shaders need to run to completion as only the final output can be written out of the GPU. Is there any reason to think this has changed with VBO, FBO and PBO? I was of the impression they are different output places, but the actual shader operation will still be a 'run to completion before output' operation.

 

[j^aws]

If I've got this right, MemExport can arbitarily send data from any point in the shader to memory, whereas ordinarily shaders need to run to completion as only the final output can be written out of the GPU.

Yeah, that's how I understand it.

With memexport, you can scatter/gather. Basically with memexport shaders, you can write (output) data to an 'arbitrary' memory address, continue doing stuff with the same shader, then read (input) that data back into the shader and continue doing stuff etc..etc.. You can also read and write to a 'reserved' memory address, e.g. an appropriate 'buffer' or texture at the same time, IIRC.

With 'normal' shaders, you can't scatter/ gather (though, IIRC, you can with certain GPGPU languages). You can't write to an 'arbitrary' memory address, only to a 'reserved' memory address. So basically the shader takes an input, does stuff, then outputs the result to a 'reserved' memory address. Then another shader takes that output as an input etc.etc..

With these two types of shaders, you can 'chain' the inputs/outputs from the appropriate memory addresses.

Is there any reason to think this has changed with VBO, FBO and PBO? I was of the impression they are different output places, but the actual shader operation will still be a 'run to completion before output' operation.

The same would apply here, with the 'normal' shaders reading/ writing to appropriate 'reserved' memory addresses, i.e buffers/ textures. However, memexport type shaders would be something that you'd want to run on the SPUs because they can scatter/gather there.

And with these two types of shaders, you can also 'chain' the inputs/outputs from the appropriate memory addresses too. So essentially the same but the shaders run on different execution resources... well that's my take on it...