The same discussion again and again... [LWN.net]

The same discussion again and again...

Posted Nov 5, 2011 10:30 UTC (Sat) by slashdot (guest, #22014)
In reply to: The same discussion again and again... by slashdot
Parent article: Rawhide gets GNOME Shell for all display types

Or to be more specific, it seems that GNOME Shell uses Clutter.

So, just write a Cairo backend for (a subset of?) Clutter, and make sure GNOME Shell can detect that it is running that way and disable anything with strictly requires OpenGL.

The same discussion again and again...

Posted Nov 7, 2011 0:03 UTC (Mon) by raven667 (subscriber, #5198) [Link] (3 responses)

Drag has it right, it doesn't make sense to implement the graphics layer twice, once using the API that the hardware implements (OpenGL) and once using a "2d" API that is not accelerated. It makes more sense to do what they are doing which is using an implementation of the graphics API which can run on the main CPU so the graphics can run either on the gpu or CPU interchangeably as fast as possible in either case

The same discussion again and again...

Posted Nov 7, 2011 6:44 UTC (Mon) by slashdot (guest, #22014) [Link] (2 responses)

2D APIs such as Cairo are normally accelerated either using OpenGL or directly accessing the 3D hardware via XRender and an EXA driver, of course.

And also they have a fast software rendering framework (Pixman) that doesn't require running a full optimizing compiler at runtime (LLVM) and is relatively simple.

Modern hardware definitely does not "implement OpenGL": OpenGL is actually an ungodly mess of extensions that requires an incredible amount of code to map to hardware.

The same discussion again and again...

Posted Nov 7, 2011 16:50 UTC (Mon) by raven667 (subscriber, #5198) [Link]

that doesn't require running a full optimizing compiler at runtime (LLVM)

I'm not an expert but I thought that graphics acceleration required a JIT compiler to translate the standard bytecode to the underlying instruction set and capabilities of the hardware. nVidia and ATI don't have the same instruction sets or system design for their GPUs. Having this process also able to target the host CPU with fully optimized fast code just makes sense.

Modern hardware definitely does not "implement OpenGL": OpenGL is actually an ungodly mess of extensions that requires an incredible amount of code to map to hardware.

You may not like aesthetically how the OpenGL API has grown organically over the years but it is the standard API for creating and running programs on the GPU. Having an optimized compiler so you can build software which targets both the GPU or CPU so graphics programs can run even when there is not dedicated hardware for them seems like a good idea.

I don't think it follows that having an incompatible "2d" backend is going to be any faster than optimizing the existing graphics API

The same discussion again and again...

Posted Nov 7, 2011 17:09 UTC (Mon) by nybble41 (subscriber, #55106) [Link]

> And also they have a fast software rendering framework (Pixman) that doesn't require running a full optimizing compiler at runtime (LLVM) and is relatively simple.

The thing is, the future of accelerated graphics on Linux (Gallium3D) already requires something like LLVM to compile hardware-agnostic shader code into binaries which can run on the GPU. It also requires CPU-based fallbacks for operations (shader code) which the GPU doesn't support efficiently. The llvmpipe software renderer is basically just a plain Gallium3D driver which relies exclusively on the fallbacks.

"Simpler", in this case, means taking advantage of the common CPU fallback code to provide a full-featured graphics driver, not relying on a completely separate software-only rendering framework with fixed primitive operations which can only be accessed via Cairo.

Due to the modularity of LLVM, much of the effort expended on optimized code generation for the x86 backend can probably be reused for various GPU backends down the road.