This might be a bit silly and uninformed, but is there a way to read and write texture (or framebuffer, GL or libdrm) memory from CPU? Without layout/format conversion, just fast direct access to the native tiled layout.
I have a vague understanding of how to do that with Vulkan, but no idea if that's something that's possible in v3d OpenGL ES with its extensions. Or even if that's a reasonable idea at all.
I'm assuming that:
- tiled layout is reasonable to (un)pack. vc4 ones are documented, and for v3d i could read kernel sources to figure out
- buffer memory access isn't "throttled" by anything extra, as it is in the same SDRAM chip. The concerning data point here is that dumb drm buffers are definitely way too slow on the pi4 and some other SBCs, but on some SBCs it's several times faster. Not sure what's up with that, probably some sync/caching page settings?
- it's possible to synchronize accesses
- the RAM bandwidth is enough to accommodate both GPU and CPU running in parallel (this has to be tested, but back-of-the-napkin suggests that it might be just enough)
- (the CPU could in fact process data fast enough; also going to test that)
A bit of context. I'm trying to do a certain frame post-processing step on CPU, as it empirically seems to be a bad match for GPU.
The frame is first rendered on a GPU, then CPU takes over, does its thing, writes directly into libdrm framebuffer in the required layout, and does the crtc flip. Ideally, GPU could render the next frame while CPU is busy.
I have a vague understanding of how to do that with Vulkan, but no idea if that's something that's possible in v3d OpenGL ES with its extensions. Or even if that's a reasonable idea at all.
I'm assuming that:
- tiled layout is reasonable to (un)pack. vc4 ones are documented, and for v3d i could read kernel sources to figure out
- buffer memory access isn't "throttled" by anything extra, as it is in the same SDRAM chip. The concerning data point here is that dumb drm buffers are definitely way too slow on the pi4 and some other SBCs, but on some SBCs it's several times faster. Not sure what's up with that, probably some sync/caching page settings?
- it's possible to synchronize accesses
- the RAM bandwidth is enough to accommodate both GPU and CPU running in parallel (this has to be tested, but back-of-the-napkin suggests that it might be just enough)
- (the CPU could in fact process data fast enough; also going to test that)
A bit of context. I'm trying to do a certain frame post-processing step on CPU, as it empirically seems to be a bad match for GPU.
The frame is first rendered on a GPU, then CPU takes over, does its thing, writes directly into libdrm framebuffer in the required layout, and does the crtc flip. Ideally, GPU could render the next frame while CPU is busy.
Statistics: Posted by provod — Fri Sep 27, 2024 5:50 pm — Replies 0 — Views 43