From: Zhigang Gong zhigang.g...@linux.intel.com
When glamor is enabled, a pixmap will not be accessed by the UXA's
accelerated function. Only un-accelerated funtion may access those
pixmap, and before each un-accelerated rendering, it calls
uxa_prepare_access which will do glFlush there.
From: Zhigang Gong zhigang.g...@linux.intel.com
As a pure glamor pixmap has a local texture rather than
bind a pixmap to a external BO. This can avoid some
unecessary flush, and can achieve better performance.
The testing on my machine shows that aa10text/rgb10text
get about 20-30% performance
From: Zhigang Gong zhigang.g...@linux.intel.com
According to your advice, split the previous 1 patch to 4.
And slightly changed the patch of create GC. The previous
verison will override the GC ops to glamor's GC ops which
is really not what I expected. If there are still some
other unexpected
On Mon, Dec 26, 2011 at 16:54:18 -0800, Keith Packard wrote:
On Mon, 26 Dec 2011 11:59:04 +0100, Kai Krakow hurikha...@gmail.com wrote:
North Bridge Configuration:
VT-d
This doesn't exist
That's odd. I don't understand all of the SNB CPU variations; perhaps
there's a desktop
From: Zhigang Gong zhigang.g...@linux.intel.com
If we are using GLAMOR, then a tile pixmap or stipple pixmap
may be pure glamor pixmap and thus UXA doesn't know how to
render to them, we should let glamor to do the validation.
Signed-off-by: Zhigang Gong zhigang.g...@linux.intel.com
---
On Mon, Dec 26, 2011 at 16:54:18 -0800, Keith Packard wrote:
On Mon, 26 Dec 2011 11:59:04 +0100, Kai Krakow hurikha...@gmail.com wrote:
North Bridge Configuration:
VT-d
This doesn't exist
That's odd. I don't understand all of the SNB CPU variations; perhaps
there's a desktop
From: Zhigang Gong zhigang.g...@linux.intel.com
Signed-off-by: Zhigang Gong zhigang.g...@linux.intel.com
---
src/intel_glamor.c | 13 -
src/intel_glamor.h |2 --
2 files changed, 0 insertions(+), 15 deletions(-)
diff --git a/src/intel_glamor.c b/src/intel_glamor.c
index
On Fri, 23 Dec 2011 12:11:10 -0800, Chad Versace chad.vers...@linux.intel.com
wrote:
The function uses libpciaccess, which is not present on Android. So, make
it a no-op that returns 0.
It's a bug that we're not using this function in mesa. How hard would
it be to get libpciaccess available?