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

[Jeremy Huddleston]

On Oct 19, 2011, at 1:02 AM, Zhigang Gong wrote:
>>> For
>>> the client
>>> side application, cairo is a good 2D libraries to utilize GPU hardware
>>> acceleration.
>>> I'm not familiar with spice. Just googled it, and it seems that it's a
>>> protocol to offload
>>> some CPU/GPU intensive tasks to remote client. I think it's also out of
>>> glamor's scope.
>> 
>> Right, but glamor's scope is defined by you, right.  Wouldn't it be better
> to
>> move this code to a higher level in the stack, so *everyone* could
> benefit.
>> As it is now, only Xephyr and Xorg benefit.  By moving it into pixman, you
>> can remove redundant code in cairo, and *every* DDX will be able to use
>> glamor.
>> 
> 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 haven't looked at the source changes yet (I prefer to have a solid high level understanding before I dissect the code).

Also, my experience with accelerated 2D in X11 has mostly been with rl_accel (2D acceleration for rootless) in the XQuartz DDX.  It's only really the past month or so that I've taken an interest in the Xorg DDX and looked more closely at things like XAA and EXA, so forgive me if my following questions are slightly off-target or have obvious answers.

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?

As I understand it, you want to allow accelerated 2D rendering at the *DIX* level (whereas EXA and XAA are for Xorg DDX drivers).  That is a great goal, but another current goal of many of us in Xorg is to eliminate the non-Xorg DDXs and replace things like XQuartz, Xnest, and Xvfb with drivers in the Xorg "DDX" ... after that is done, hw/xfree86 will actually be device-independent and we can start refactoring the current DIX/DDX boundary.

At that point, where does glamor fit into the picture, and why does it need to be in the server itself?

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.

How difficult would it be to rework this as a standalone library?

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