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
signature.asc
Description: Digital signature
_______________________________________________ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
