access current framebuffer from kernel

Accelerated Computing CUDA CUDA Programming and Performance
1

Hello all!

I want to program a kernel that will somehow access the current framebuffer and perform some computations on the pixels.

Is it possible to access directly the framebuffer from a kernel? If not, what is the best way to do this?

Thanks in advance!

2

anything?

3

There are many examples in sdk of doing it.

4

Thanks for the answer!

Actually, I want to access the framebuffer of the whole screen, and not of an object. Is that possible??

Best Regards!

5

Well then capture the screen, send it to CUDA. There should be examples how to do this (not part of the CUDA SDK) on the Internet.

6

Well, I wonder if it is feasible to access the buffer directly from the GPU, and eliminate this extra copy. I mean, the pixels that are displayed on the screen should be somewhere in the GPU memory, right? – isn’t is possible to access them somehow or are they memory protected?

7

protected

8

thanks for your response!

however, i can’t clearly see the reason behind this… is there any links/documentation that describes the gpu systems architecture in more depth?

many thanks!

9

If you did not allocate memory, you are not allowed to touch it, like with all programs you write.

10

Look again: Pixel-perfect copies of copyrighted material.

11

do you know if the driver is responsible for this memory checking or the hardware?

12

This is just a guess but I would suspect that it is a combination of the two. Several experiments have revealed that GPUs have TLBs, which suggests that there is hardware support for detecting out of bounds memory accesses. If you have a TLB then something has to program it, on CPUs is this the OS, on GPUs it is probably the driver.

13

I don’t think that that is it since there are screen capture solutions (search for bitblt). They are just not too efficient and do have some limitations.

The problem is that the GPU has virtual memory of some sort (allocating one buffer each in two threads returns the same pointer to both threads pointing to different locations in memory, 0x11000 or something like that)

The problem is that the memory is in different contexts, and you want to protect one program from another (malicious programs and program bugs).

14

Maybe it is implemented in the cuda library. Actually, the command strings /usr/lib/libcuda.so | grep -i tlb gives some output.