Dedicated GPUs vs IGP/Mobile

jakovo said:
I'm not familiar with Mobile, so was curious about how come IGP/Mobile GPU's require more CPU assistance than dedicated GPUS (such as NVIDIA/ATI)?… If I was going to write graphcis engine targeting both what kind of CPU assistance IGP/Mobile would require not present on dedicated hardware?

Can't say I've heard it described as “CPU assistance”, but I think he's referencing limited bandwidth, power, etc on mobile requires a different approach and/or avoidance of certain workloads that might otherwise be taken for granted on desktop. Specifically you're going to deal more with the constraints of limited bandwidth, limited graphics memory (GMEM), and tiled rendering architectures.

A lot of issues revolve around algorithms that use more bandwidth or require multiple touches with GMEM. Basically - you want to minimize your GMEM Loads (or unresolves). The specifics of that will vary depending on the algorithm but a lot of mobile GPU performance comes back to the effect of GMEM and the tiling architecture.

Oculus actually has a great guide that, while written for their VR platforms, is a pretty good primer for any developer going from desktop to mobile GPU's.

Thanks for your response, khawk!

I've just finished reading the guide you suggested, very enlightening indeed.

Do Integrated Graphics Processors suffer from the same constraints?… or why would you think the tweet thread mentioned that both Mobile devices and IGP should be targeted the same?

(At least IGPs don't do tile rendering AFAIK)

thanks!

I have switched to software rendering years ago in my engines, because i didn't wanted to waste my life on trying to optimize renderers on 20+ manufacturers 500 hardware and hunt for mistic bugs and crashes continously (and lose money and clients).

If you write a for cycle and you start rendering random textured triangles and measure the fps, then of course you get good performance on every video hardware. This was true for s3 virge and voodoo1, and this is true even 25 years later on your mali and vivante... The problems instead will arise if you start to use the complex features, more you rely on the drivers, exponentially the number of problems and bugs will increase (unexpected slowdowns, crashes, missing textures, white screens, glitches, lockups, memory leaks, garbled textures).

When he used the require more CPU assistance phrase, he worded the sentence like that so the parameciums can understand his tweets too (which is probably the target audience of his engine).

The problem is that since the advent of “batch batch batch” 3D hardware and APIs have been developing in a way that's the opposite of how people actually want or need to use them. So what we have now is relatively inflexible shader stages, big monolithic state objects, everything needing to be specified and laid out in advance of usage, data and state requiring to be static everywhere, and the resulting management headaches caused by inevitable combinatorial explosion. And meanwhile the whole thing maps less and less well to different hardware types and architectures

This was really the crux of John Carmack's old OpenGL vs Direct3D rant. API syntactical style and open vs proprietary were just side issues, distractions; ease of use and productivity were the key points.

It's obviously not impossible. People can and do quite successfully write programs in this kind of ecosystem. But is it as productive as it can be? Is it even productive at all? .

It can't be denied that the old APIs needed revision. The draw call problem was real. OpenGL in particular badly needed a clean up and simplification pass. But did we need what we got? Or could the old problems have been solved in a way that's not going to cause a bunch of new problems?