[Pull v2] Glamor - fixed build failure, fixed coding style problem.

[Jamey Sharp]

On Wed, Oct 19, 2011 at 11:20:54AM -0700, Jeremy Huddleston wrote:
> On Oct 19, 2011, at 1:02 AM, Zhigang Gong wrote:
> > Just as I said above. Your thought do make sense. Currently glamor
> > implements some GL based rendering functions. And in the long term,
> > we may merge those functions into cairo or pixman, and let glamor
> > call them directly. Just as the relation between libfb(which belongs
> > to X server) and pixman.
> > 
> > To achieve that goal, I think we still need more time. And now I
> > want to open glamor at this point, and move to that direction step
> > by step. And eventually, there will be a thinner glamor module. 

I completely understand your desire to get this merged. Until that
happens you can't have a clear idea of how to make further progress.
Unfortunately, that's exactly why open source communities need to hear
about projects like this earlier in the development cycle. Earlier
notice lets us tell you about problems or concerns before you do so much
work, and gets you community support for your project while you work on
it.

Since that didn't happen this time, we have a bigger challenge: how can
we work with you to make sure your effort isn't wasted? Although I'm
very excited to see effort toward implementing 2D acceleration with 3D
drivers, I'm sorry to say that I don't think this method of integrating
it should be merged. I do have an alternative proposal, though, below.

> What existing problem does your solution solve?  Can you give me an
> example of a configuration which doesn't have 2D acceleration now
> which will with glamor or a case where 2D performance has
> significantly improved by switching to your codepath?

To partially answer these questions: glamor is a great idea in principle
for at least two cases.

I've been listening to driver developers moan for years about having to
write a 2D driver, then turn around and write a separate 3D driver,
every time a new piece of hardware comes out. Glamor may enable writing
only a kernel modesetting driver and a Mesa 3D driver, and using the
generic xf86-video-modesetting userspace driver for 2D X.

For nested X (Xnest/Xephyr/Xdmx/xf86-video-nested), glamor could reduce
or eliminate the software-render-and-PutImage cycle, instead letting the
backend X server use suitably accelerated 3D. In the case where the
backend server is on the same machine as the nested server, the nested
server should wind up direct-rendering straight to the video hardware.

Based on public statements from Intel developers I'd speculate that
they're interested in both cases. I don't know what will happen with
Tizen, but the Meego development environment used Xephyr as the fake
phone screen, and apparently its lack of rendering performance was
painful. And of course like any good developers, the graphics team is
lazy and would like to spend less effort on writing drivers. :-)

Jeremy, if glamor works out, OS X should benefit eventually too. Ideally
you'll have a variant of xf86-video-dummy that direct-renders to
offscreen video memory, which you'd composite into native windows using
GL handles. Glamor ought to enable 2D offscreen acceleration there too.

> We want to minimize the API boundary between the server and its
> drivers.  Rather than provide a server module which will present
> glamor API exposed by the Xserver for drivers to use, I'd prefer you
> provide this as a library that drivers (or even non-Xorg DDX) can link
> against.

Just so this is very clear: The *reason* we want to minimize the
server's API boundary is because anything that we expose in the server's
API, we have to continue to support. That ongoing support burden is why
Jeremy is pushing you to expose this functionality in a different way.

Here's my proposal: extract what you have in xserver/glamor as a
library, then use that library in xf86-video-modesetting (instead of the
glamor DDX) and xf86-video-nested (instead of Xephyr). Dave Airlie has
put a lot of work into the modesetting driver over the past few weeks,
and Jeremy and I have been working on the nested driver, so hopefully
you can get community support for any issues you run into in those
drivers.

> XGL tried to solve this same problem ... how do we know this won't
> flop?

This is also like Xgl, as I recall, in that Xgl was a large development
effort happening inside a company (Novell, in that case) and then being
dropped on the X.Org community. I'd say that had a lot to do with it
eventually failing.

A bunch of this work has Eric Anholt's and Kristian Høgsberg's names on
it, and I'd have expected them to remember that debacle.

Jamey
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://lists.x.org/archives/xorg-devel/attachments/20111020/83af8a11/attachment.pgp>