On Thu, Nov 22, 2012 at 5:59 AM, Alan Cox <a...@lxorguk.ukuu.org.uk> wrote:
> On Thu, 22 Nov 2012 05:47:30 -0500 > "Jasper St. Pierre" <jstpie...@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
_______________________________________________ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
