Member Avatar for Mohamad89

Hello,
I am currently doing a research at my university about the ways in which we can use multicore CPU to enhance graphics performance instead of putting all the load on the GPU, I am trying to work with both OpenGL and OpenMP and I am planning on using gDebugger to measure performance but I am stuck due the lack of information and papers about this subject so if anyone has any knowledge or any contribution or suggestion please do let me know.

Thanks.

  • 3 Contributors
  • 2 Replies
  • 311 Views
  • 1 Week Discussion Span
  • Latest Post Latest Post by jbennet

Dani AI

Generated

Follow-up note for with extra, practical direction that builds on and without repeating their suggestions.

Multicore CPUs help most when they do the work GPUs are not ideal at: per-frame culling, LOD selection, skinning/animation, occlusion tests, stream/asset preparation, and building compact draw lists or indirect command buffers. OpenGL contexts are thread-local (a single context cannot be current on two threads at once), so the safe pattern is: let worker threads produce GPU-ready data, then have one thread perform the actual GL submission. (See the Khronos notes on context/threading.) https://www.khronos.org/opengl/wiki/OpenGL_Context

A robust implementation pattern that scales on many cores:

  • Parallel workers compute visibility/skin/LOD and append small DrawCommand records into per-thread staging arrays.
  • Merge or concatenate those arrays into a GPU-visible staging region (use immutable storage + persistent mapping where available), then issue a single multi-draw call from the GL thread. This avoids issuing thousands of GL calls from many threads and minimizes stalls. Relevant APIs: persistent mapped buffers and indirect-draw commands. https://docs.gl/gl4/glBufferStorage https://docs.gl/gl4/glMultiDrawElementsIndirect

If your goal is true multi-threaded command recording, consider moving to APIs designed for that use-case (Vulkan / D3D12) — they let host threads record command buffers in parallel and then submit them cheaply. https://docs.vulkan.org/guide/latest/threading.html

Useful references and examples: Mesa’s LLVMpipe shows a multithreaded CPU software rasterizer (good study material for software-render ideas), and open-source frame debuggers like RenderDoc / vendor tools help correlate CPU and GPU hotspots. https://docs.mesa3d.org/drivers/llvmpipe.html https://github.com/baldurk/renderdoc

Minimal per-frame pseudocode (illustrative):

parallel: compute visibility -> push DrawCmd to thread-local vector
main: copy/merge vectors into persistent mapped indirect buffer
main: glMemoryBarrier(...); glMultiDrawElementsIndirect(...);

Notes: OpenMP is useful for the data-parallel parts (culling/mesh skinning), but avoid calling GL from arbitrary OpenMP threads — keep GL calls serialized or use shared contexts carefully. See OpenMP and OpenGL threading docs when designing synchronization. https://www.openmp.org/spec-html/5.1/openmpch1.html

Recommended Answers

All 2 Replies

Member Avatar for Skeen

Hello,
I am currently doing a research at my university about the ways in which we can use multicore CPU to enhance graphics performance instead of putting all the load on the GPU, I am trying to work with both OpenGL and OpenMP and I am planning on using gDebugger to measure performance but I am stuck due the lack of information and papers about this subject so if anyone has any knowledge or any contribution or suggestion please do let me know.

Thanks.

Why would you run graphics on the CPU, when the GPU is made for it, and builded upon multi thread architecture? - and how, will you be building like your own kernel or?

About using OpenMP among with OpenGL, then it's pretty much just writing everything into parallel loops, a good way to do this, could be to make a multi layered buffer, and instead of just swapping the buffer, after showing an "image", then you'll swap to the next image, in a buffer of like 10frames (you'll be able to achive higher frame rates by doing this, simply by swapping the buffer, when like the 2next images are ready in the buffer.), All you will need to then is really to multi thread the buffer filling display function, using OpenMP, with something like; "#pragma omp parallel for", another thing you could do is, OpenMP into the main display function, however you'll need to keep threads alive then, to avoid a lot of overhead. - but still, I would prefer using my GPU for the display :)

Member Avatar for jbennet

I am currently doing a research at my university about the ways in which we can use multicore CPU to enhance graphics performance instead of putting all the load on the GPU

Been tried already. Before vista/aero, windows handled the drawing of all windows using GDI so they were rendered by the CPU. MS with vista changed it so DWM used the GPU instead for this. This was when multi-cores were becoming popular, so obviously MS thaught it would be better to do it that way. Probably a whitepaper on MSDN somewhere.

Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.