PDA

View Full Version : Direct Texture access



inwu00
07-12-2010, 01:23 PM
Is there a way that I can direct access the texture data that stored in the video memory? glTexSubImage2D is actually 2 two steps process. You need to update the local memory first and then copy to the video memory. PBO seems to be a good concept but it's actually slower then without PBO? I don't understand why OpenGL doesn't allow user to do that? Any comment?

ZbuffeR
07-12-2010, 02:16 PM
Video card can not use a texture while you are accessing it.
Try with 2 PBO, one used by video card, one updated from you app, then swap.
If it is still slower, then you are likely to do it wrong.

kyle_
07-12-2010, 02:57 PM
Its understandable that texture memory is not mappable - textures are likely to be tiled, so accessing its bytes directly may not be meaningful without this information in the api.

inwu00
07-12-2010, 04:59 PM
The reason I use OpenGL is because they remove the Intel DGA driver (2D acceleration) for Linux. Our application is to display real-time medical image and info. Take EKG waveform for example. It's a 3 step operation:
1. Blit background image to back buffer (video memory).
2. Draw Wavefrom on top of background. (Pixel by pixel on video memory)
3. Blit the result into main display.

The hw blit is very fast and CPU only spends time on drawing pixels.

On the contrary, OpenGL require CPU to do all the jobs.
1. CPU copy the background to local memory.
2. CPU draws Waveform on local memory.
3. CPU copy the result from local memory to video memory.

Correct me if I am wrong!

dorbie
07-12-2010, 09:26 PM
Video card can not use a texture while you are accessing it.
Try with 2 PBO, one used by video card, one updated from you app, then swap.
If it is still slower, then you are likely to do it wrong.

The whole concept is doing it wrong.

That simple swap can imply a LOT of work.

Keep rendering on the graphics card. If you need fine grained CPU software access to the buffer then THAT is doing it wrong at a fundamental level unless it's unavoidable.

... and by unavoidable, I don't mean inconvenient, or that you have some shitty legacy crapware to run. If you want to turn your hardware accelerator into a deccelerator then by all means access the framebuffer using the CPU, knock yourself out.

dorbie
07-12-2010, 09:30 PM
Use OpenGL to draw the waveform, don't do it pixel by pixel.

Get it in a VBO or an FBO. This will block transfer it, then rasterize it using the OpenGL pipeline. Do NOT, ***NOT*** attempt to rasterize the data using the CPU.

You can get VERY creative with how a vertex or fragment shader addresses data, including dependent reads. Use the GPU.

dorbie
07-12-2010, 09:40 PM
P.S. incase it's not clear from this, I could for example write a shader to have a very small 1D FBO texture with graph values and drive a rectangle rasterization with a quad and then do a compare in the fragment shader or a non branching threshold of some kind to produce a solid graph.

This is just one on MANY options to rasterize, probably not even the best as it's fill inefficient but a modern GPU can do this better than it can support CPU buffer access, YMMV depending on the details of your problem. The point is to send minimal data to the GPU using efficient mechanisms and have hardware rasterize using that data.