Re: Dropping fallback mode in 3.8

["Jasper St. Pierre" <jstpierre mecheye net>]

On Thu, Nov 22, 2012 at 5:59 AM, Alan Cox <alan lxorguk ukuu org uk> wrote:

On Thu, 22 Nov 2012 05:47:30 -0500
"Jasper St. Pierre" <jstpierre mecheye net> wrote:

> The hardware accelerated graphics API that the rest of the world has
> depended upon is OpenGL, minus Direct3D for obvious reasons. It's
> unfortunate, but if OpenGL isn't supported on these devices, a hardware
> accelerated desktop isn't going to be possible. I don't think it's worth it
> to write hardware acceleration code because the driver maintainers couldn't
> give us the API that everybody else has.

LLVMpipe gives you that API

Sure. It's not hardware-accelerated, though, which is the issue we're discussing with PowerVR. If they implement what we need in terms of a hardware-accelerated graphics rendering API (OpenGL, plus a few extensions here and there), things should start to work.
 

> The issue should be fixed at the driver level, not at the GNOME level.

You can't fix it at the driver level or that easily at the Gl level. The
problem you have is that Gl type rendering doesn't allow the stack
sufficient ability to identify optimisations for what is basically for
the most part 2D abuse of the 3D API. In addition it is more CPU
intensive to do Gl emulation which in todays world means that it costs
power and thus battery life.

Sure, we can argue about whether GL is a good API for what we're doing, and design better APIs for rendering 2D graphics efficiently (XRender, anyone?), but a simple fact remains: OpenGL is the API we have for doing hardware-accelerated graphics rendering, like it or not.

Implementing a software renderer for gnome-shell / Clutter isn't on my list of things to do in the near future.
 

Hence you need to do it higher up the stack where you have the
information needed. E does this and that is why E is very fast on just
about any hardware.

 

You also need to be aware of much of this higher up anyway even in the
OpenGL world because you need to adjust your options and effects based on
the timing and performance currently being received do that you can for
example dynamically drop out some of the effects on a box under load, or
perhaps on a low clock in battery mode.

Alan

--
  Jasper