The patchset LGTM and works well with beignet. The 80%+ performance regression
issue in darktable also has been fixed
after this patchset applied and enable the atomic in L3 at beignet side. So,
Reviewed-by: Zhigang Gong
Thanks,
Zhigang Gong.
> -Original Message-
> From: Fra
o you have any suggestion here?
Thanks,
Zhigang Gong.
> -Original Message-
> From: Beignet [mailto:beignet-boun...@lists.freedesktop.org] On Behalf Of
> Andi Kleen
> Sent: Thursday, April 30, 2015 12:19 PM
> To: beig...@lists.freedesktop.org
> Cc: zhigang.g...@linux.intel
n towards FULL
SVM function.
From OCL's view, it is usefull for the 2.0's. There are three types of SVM
options. Even for the most basic "Coarse-Grained buffer SVM", something like
MAP_FIXED is useful. Becuase it needs to pass a linked list object to the
OCL kernel dir
e code into this block.
#endif
Then we can avoid put the same definitions in different files,
and we can avoid unecessary testing on an old kernel which doesn't
have this kernel interface.
For all the other part, it LGTM.
Reviewed-by: Zhigang Gong
Thanks,
Zhigang Gong.
On Thu, Mar 12,
LGTM,
Reviewed-by: Zhigang Gong
Thanks.
> -Original Message-
> From: Beignet [mailto:beignet-boun...@lists.freedesktop.org] On Behalf Of
> jeff.mc...@intel.com
> Sent: Tuesday, March 10, 2015 7:36 AM
> To: beig...@lists.freedesktop.org
> Cc: intel-gfx@lists.freed
This patchset is a must for beignet to support CHV. One comment is that we
should
put the usage of these new libdrm APIs to conditional block thus we don't break
the
build on old system.
For the other parts of the patchset:
Reviewed-by: Zhigang Gong
Thanks,
Zhigang Gong.
> -
> -Original Message-
> From: Beignet [mailto:beignet-boun...@lists.freedesktop.org] On Behalf Of
> Jeff McGee
> Sent: Saturday, March 7, 2015 2:44 AM
> To: Zhigang Gong
> Cc: dan...@ffwll.ch; intel-gfx@lists.freedesktop.org;
> beig...@lists.freedesktop.org; dri-de...@
forms, it works fine.
Thanks,
Zhigang Gong.
On Mon, Mar 02, 2015 at 03:37:32PM -0800, jeff.mc...@intel.com wrote:
> From: Jeff McGee
>
> Setup new I915_GETPARAM ioctl entries for subslice total and
> EU total. Userspace drivers need these values when constructing
> GPGPU command
On Mon, Jan 05, 2015 at 07:27:26PM +0200, Francisco Jerez wrote:
> Zhigang Gong writes:
>
> > On Mon, Jan 05, 2015 at 05:03:16AM +0200, Francisco Jerez wrote:
> >> Zhigang Gong writes:
> >>
> >> > According to bspec, ROW_CHICKEN3's bit 6 whic
On Mon, Jan 05, 2015 at 05:03:16AM +0200, Francisco Jerez wrote:
> Zhigang Gong writes:
>
> > According to bspec, ROW_CHICKEN3's bit 6 which is to disable
> > move of cacheable global atomics to L3 is needed for GT3 D
> > stepping.
> >
> > I enabled it
with some workload, for an example, the "splat" kernel in darktable,
without this patch, it consumes 50 seconds in one large raw picture processing.
But with this patch, the same process only takes less than 1 second.
Signed-off-by: Zhigang Gong
---
drivers/gpu/drm/i915/intel_pm.c | 1
Vasily,
Could you try ImageMagick(convert) again with latest git master
beignet(git-e46764f). It should work now.
Thanks,
Zhigang Gong.
On Fri, Oct 24, 2014 at 04:36:49PM +0300, Vasily Khoruzhick wrote:
> Hi Zhigang,
>
> On Fri, Oct 24, 2014 at 12:13 PM, Zhigang Gong
> w
I confirm that the second case is indeed a beignet
bug. Beignet lacks of some llvm intrinsics support such as
llvm.uadd.with.overflow.i32().
Will fix it next week.
Thanks,
Zhigang Gong.
>
> And convert from imagemagick crashes in libgbe.so:
>
> Program received signal SIGSEGV, Seg
ld be reproduced easily, please open a bug on fd.o.
Thanks,
Zhigang Gong.
On Fri, Oct 24, 2014 at 10:27:23AM +0800, Zhigang Gong wrote:
> Hi,
>
> For IVB, I just checked the 3.18-rc1, it has the following patch:
> commit c9224faa59c3071ecfa2d4b24592f4eb61e57069
> Author: Brad Volki
l-gfx mail list as below and it doesn't
sound good.
http://lists.freedesktop.org/archives/intel-gfx/2014-May/044694.html
http://lists.freedesktop.org/archives/intel-gfx/2014-May/045088.html
CC to intel-gfx mail list. Hope we can get an official anwser here.
Thanks,
Zhigang Gong.
On Thu, Oct 2
Dave Airlie just implemented some Xv support as below, although not fully
support all functions.
But currently, we haven't enable it in Intel's driver side.
commit bad96d415525b12add517b09a26b52c2c36979f7
Author: Dave Airlie
Date: Mon Sep 23 06:42:24 2013 +0100
glamor: add initial Xv suppo
> -Original Message-
> From:
> intel-gfx-bounces+zhigang.gong=linux.intel@lists.freedesktop.org
> [mailto:intel-gfx-bounces+zhigang.gong=linux.intel.com@lists.freedesktop.
> org] On Behalf Of Zou, Nanhai
> Sent: Tuesday, April 16, 2013 2:47 PM
> To: Dave Airlie
> Cc: intel-gfx@lists.f
On Tue, Aug 21, 2012 at 12:51 PM, Rémi Cardona wrote:
> Hi Zhigang,
>
> Le vendredi 10 août 2012 à 18:37 +0800, Zhigang Gong a écrit :
>> tar ball is at:
>>
>> http://cgit.freedesktop.org/xorg/driver/glamor/snapshot/glamor-0.5.tar.gz
>
> This is a git snapshot, no
On Sat, Aug 11, 2012 at 10:55:08AM +0200, Paul Menzel wrote:
> Dear Zhigang,
>
>
> thank you for the announcement message and congratulations on the
> release. But please do not send HTML messages to lists [1]!
Thanks for pointing this out. Actually, I was not aware of that I
sent any non plain-
On Fri, Aug 10, 2012 at 08:58:33AM -0700, Jeremy Huddleston Sequoia wrote:
>
> On Aug 10, 2012, at 03:37, Zhigang Gong wrote:
>
> > to try a full functional xserver with glamor, it’s recommended to use the
> > following xserver version:
> >
> > commit a615b90
o generate the temp trapezoid mask
Zhigang Gong (43):
We should not call gradient finalization code if we disable it.
Added strict warning flags to CFLAGS.
Remove the texture cache code.
glamor_set_destination_pixmap_priv_nc: set drawable's
glamor_pixmap is only true for FrontLeft, mind resending with this
> simplification?
Sure, the simplified version is as below. Thanks.
>From 6224fb9839f417cdd412667f4e6f502df872e7aa Mon Sep 17 00:00:00 2001
From: Zhigang Gong
Date: Fri, 27 Jul 2012 16:50:52 +0800
Subject: [PATCH] uxa_gl
From: Zhigang Gong
The previous implementation is to create a new textured
pixmap based on the newly created pixmap's buffer object.
This is not efficient, as we already created it when we
call CreatePixmap. We can just exchange the underlying
texture/image buffers by ca
From: Zhigang Gong
glamor_glyphs will never fallback. We don't need to keep a
uxa glyphs cache picture here. Thus simply bypass the
corresponding operations.
Signed-off-by: Zhigang Gong
---
uxa/uxa-glyphs.c | 12 +++-
1 files changed, 11 insertions(+), 1 deletions(-)
diff --
From: Zhigang Gong
We need to put current front_buffer to back buffer thus we
don't need to create a new back buffer next time. This behaviou
should be the same with or without glamor. Previous code
incorrectly discard the previous front_buffer and cause a
big buffer leak problem.
Signed-o
From: Zhigang Gong
Two fixes in this commit, first we only need to check the
front left buffer, for other attachment we don't need to
check them. The second is, we should fixup the pixmap's
drawable not the original drawable.
Signed-off-by: Zhigang Gong
---
src/intel_dr
From: Zhigang Gong
To support easy buffer exchange at glamor layer, glamor
added a new API glamor_egl_exchange_buffers() to exchange
two pixmaps' EGL image and fbos and textures without
recreating any of them. But this simple method's requirement
is that there are two pixmaps. A except
From: Zhigang Gong
Add a new element back_name to intel structure to track
the back bo's name then avoid flink every time.
And at function I830DRI2ExchangeBuffers, after finish
the BO exchange between info's front and back pixmap,
it set the new front bo to the screen pixmap. But
or: Use a macro to specify module name.
>
> From: Zhigang Gong
>
> Signed-off-by: Zhigang Gong
> ---
> src/intel_glamor.c |2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/src/intel_glamor.c b/src/intel_glamor.c index
446dd3d..f908b7c
&g
> -Original Message-
> From:
> intel-gfx-bounces+zhigang.gong=linux.intel@lists.freedesktop.org
> [mailto:intel-gfx-bounces+zhigang.gong=linux.intel.com@lists.freedesktop.
> org] On Behalf Of Zhigang Gong
> Sent: Thursday, February 02, 2012 5:45 PM
> To: ch...@ch
From: Zhigang Gong
Should modify the old pixmap's header not the new one which
was already destroyed.
Signed-off-by: Zhigang Gong
---
src/intel_dri.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/src/intel_dri.c b/src/intel_dri.c
index 0c6d45c..8bc6157 100644
Refine CloseScreen and InitScreen process.
>
> From: Zhigang Gong
>
> The previous version calls glamor_egl_close_screen and
> glamor_egl_free_screen manually which is not align with standard process.
> Now glamor change the way to follow standard method:
>
> glamor
to specify module name.
>
> On Thu, 2 Feb 2012 11:30:57 +0800, zhigang.g...@linux.intel.com
> wrote:
> > From: Zhigang Gong
>
> Would be good to mention which commit introduces the macro into
> glamor, just to serve as a reminder that one needs to update. Same for
From: Zhigang Gong
Signed-off-by: Zhigang Gong
---
src/intel_glamor.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/src/intel_glamor.c b/src/intel_glamor.c
index 446dd3d..f908b7c 100644
--- a/src/intel_glamor.c
+++ b/src/intel_glamor.c
@@ -67,7 +67,7
From: Zhigang Gong
The previous version calls glamor_egl_close_screen and
glamor_egl_free_screen manually which is not align with
standard process. Now glamor change the way to follow
standard method:
glamor layer and glamor egl layer both have their internal
CloseScreens. The correct sequence
From: Zhigang Gong
Chris,
According to your previous comments. The X server will not die when
fail to get a dri buffer for a glamor pixmap, instead it will return
a BadAlloc. Your previous advice is to pass a BadMatch to the client,
and I traced into X's dri2 module and found current cod
gmail.com
> Cc: intel-gfx@lists.freedesktop.org; zhigang.g...@linux.intel.com;
> zhigang.g...@gmail.com; gla...@lists.freedesktop.org
> Subject: Re: [Glamor] [PATCH v2] uxa/glamor: Create glamor pixmap by
> default.
>
> On Wed, 11 Jan 2012 10:01:09 +0800, zhigang.g...@gmail.com w
From: Zhigang Gong
A minor fix, after convert the old pixmap to the textured-drm pixmap,
we need to modify the old pixmap's header to make sure the width/height
and stride are the same as the new textured-drm BO.
---
As create glamor pixmap by default will get much better performance
by
From: Zhigang Gong
As create glamor pixmap by default will get much better performance
by using the textured-drm pixmap, this commit is to make that the
default behaviour when configure to use glamor.
A side effect is that for those glamor pixmaps, they don't have a
valid BO attached to i
PATCH 0/1] uxa/glamor: Route some drawing function to
> glamor.
>
> On Sat, 31 Dec 2011 21:18:14 +0800, zhigang.g...@linux.intel.com
> wrote:
> > From: Zhigang Gong
> >
> > I agree to pending the last patch which is to create glamor pixmap by
> default.
> > This
From: Zhigang Gong
We have to route all the drawing function to glamor at first
if glamor is enabled. The previous commit missed some function.
Now add them in.
Signed-off-by: Zhigang Gong
---
uxa/uxa-accel.c | 142 --
uxa/uxa-glamor.h
From: Zhigang Gong
I agree to pending the last patch which is to create glamor pixmap by default.
This patch is based on the other 3 patch. After apply this patch, and use
the latest glamor. I spent too much time to fix those XTS regressions this week
and haven't have a chance to add ve
PATCH 4/4] uxa/glamor: Create glamor pixmap by default.
>
> On Tue, 27 Dec 2011 17:09:18 +0800, zhigang.g...@linux.intel.com
> wrote:
> > From: Zhigang Gong
> >
> > As a pure glamor pixmap has a local texture rather than bind a pixmap
> > to a external BO. This can a
From: Zhigang Gong
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 improvement.
Signed-off-by
From: Zhigang Gong
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
---
uxa/uxa-glamor.h |1 +
uxa/uxa.c|
From: Zhigang Gong
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.
Signed-off-by: Zhigang
From: Zhigang Gong
Signed-off-by: Zhigang Gong
---
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 8daa4b1..2b56ae5 100644
--- a/src/intel_glamor.c
+++ b/src
From: Zhigang Gong
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 side effects, please he
From: Zhigang Gong
Prefer to create a pure glamor pixmap rather than a BO and then
create a texture from that BO in glamor. As this will avoid some
glFlush requirements, it can get about 20-30% performance gain.
When glamor is enabled, route the uxa_create_gc to glamor_create_gc.
This commit
> -Original Message-
> From: Chris Wilson [mailto:ch...@chris-wilson.co.uk]
> Sent: Friday, December 16, 2011 5:21 PM
> To: zhigang.g...@linux.intel.com
> Cc: intel-gfx@lists.freedesktop.org; zhigang.g...@gmail.com; Zhigang
> Gong
> Subject: Re: [PATCH] uxa/glamor: F
Forgot to mention that to access that link need to be in Intel intranet
environment.
From: intel-gfx-bounces+zhigang.gong=linux.intel@lists.freedesktop.org
[mailto:intel-gfx-bounces+zhigang.gong=linux.intel@lists.freedesktop.org
] On Behalf Of Zhigang Gong
Sent: Friday, December 16
Hi Chris,
I tested a browser case with latest UXA code and experienced X crashed.
I bisected it and found that it was introduced by
commit 5d5b2b8ee203ae2274fc7d13ed38d2945facca9e.
The back trace of the crash is as below:
Backtrace:
0: /home/gongzg/gfx-dev-test/src/xserver/hw/xfree
From: Zhigang Gong
If we failed to create textured pixmap from BO's handle, we
turn to create a new glamor pixmap by call glamor_create_pixmap
rather than fallback to in-memory pixmap. Have to introduce
a new wrapper function intel_glamor_create_pixmap.
Signed-off-by: Zhigang Gong
---
> -Original Message-
> From: Chris Wilson [mailto:ch...@chris-wilson.co.uk]
> Sent: Wednesday, December 14, 2011 7:12 PM
> To: Zhigang Gong
> Cc: intel-gfx@lists.freedesktop.org; zhigang.g...@gmail.com
> Subject: RE: [PATCH] uxa/glamor: Enable the rest glamor rendering
&g
e: [PATCH] uxa/glamor: Enable the rest glamor rendering
> functions.
>
> On Tue, 13 Dec 2011 22:31:41 +0800, zhigang.g...@linux.intel.com
> wrote:
> > From: Zhigang Gong
> >
> > This commit enable all the rest glamor rendering functions.
> > Tested with latest glamor
e: [PATCH] uxa/glamor: Enable the rest glamor rendering
> functions.
>
> On Tue, 13 Dec 2011 22:31:41 +0800, zhigang.g...@linux.intel.com
> wrote:
> > From: Zhigang Gong
> >
> > This commit enable all the rest glamor rendering functions.
> > Tested with latest glam
From: Zhigang Gong
This commit enable all the rest glamor rendering functions.
Tested with latest glamor master branch, can pass rendercheck.
One thing need to be pointed out is the picture's handling.
Pictures support many different color formats, but glamor's
texture only support a
> -Original Message-
> From: Chris Wilson [mailto:ch...@chris-wilson.co.uk]
> Sent: Thursday, November 17, 2011 6:57 PM
> To: Zhigang Gong; intel-gfx@lists.freedesktop.org
> Subject: RE: [PATCH 0/2] Introduce Glamor to UXA framework.
>
> On Thu, 17 Nov 2011 18:49:49
> -Original Message-
> From: Chris Wilson [mailto:ch...@chris-wilson.co.uk]
> Sent: Thursday, November 17, 2011 5:20 PM
> To: Zhigang Gong; intel-gfx@lists.freedesktop.org
> Subject: RE: [PATCH 0/2] Introduce Glamor to UXA framework.
>
> On Thu, 17 Nov 2011 10:55:39
> -Original Message-
> From: Chris Wilson [mailto:ch...@chris-wilson.co.uk]
> Sent: Thursday, November 17, 2011 9:14 AM
> To: Zhigang Gong; intel-gfx@lists.freedesktop.org
> Cc: zhigang.g...@linux.intel.com
> Subject: Re: [PATCH 0/2] Introduce Glamor to UXA framework.
&
, for example, in
intel_flush_callback and couple of places in intel_display.c.
This commit only enables two glamor functions for
fill_spans and poly_fill_rects. Will continue to enable the
reset glamor functions soon.
Signed-off-by: Zhigang Gong
---
src/Makefile.am |6 +--
src/intel.h
e
configuration.
Reviewed-by: Eugeni Dodonov
Signed-off-by: Zhigang Gong
---
configure.ac | 17 +++
src/Makefile.am|5 ++
src/intel_glamor.c | 130
src/intel_glamor.h | 45 ++
4 files changed, 197 insertions(
After discussion with Chris yesterday, I reworked the previous
glamor branch and concentrate the patchset to two patches. The
first patch is the same as the previous. The second patch merges
all the others into one, and made some slightly change. One major
change is that I decide to extent the f
> -Original Message-
> From: Chris Wilson [mailto:ch...@chris-wilson.co.uk]
> Sent: Tuesday, November 15, 2011 8:25 PM
> To: Zhigang Gong; intel-gfx@lists.freedesktop.org
> Cc: zhigang.g...@linux.intel.com
> Subject: Re: [PATCH 2/2] glamor: Address GLAMOR/UXA flushing pr
O, we also need to flush all the
pending GL operations.
The scenario 2 could be eliminated when we fully change to glamor
path.
Signed-off-by: Zhigang Gong
---
src/intel_glamor.c | 13 -
src/intel_uxa.c|8 +++-
uxa/uxa-accel.c| 30 --
uxa/
Address Chris comment. We concentrate all the flag check into
intel_glamor layer which makes the interface to glamor
self-contained.
Signed-off-by: Zhigang Gong
---
src/Makefile.am|6 +---
src/intel_driver.c | 25 +
src/intel_glamor.c | 75
ff-by: Zhigang Gong
---
src/intel_driver.c |2 --
src/intel_uxa.c|2 --
uxa/uxa-accel.c|5 -
3 files changed, 4 insertions(+), 5 deletions(-)
diff --git a/src/intel_driver.c b/src/intel_driver.c
index bd57694..0f528f3 100644
--- a/src/intel_driver.c
+++ b/src/intel_driver.c
@@
According to Chris's comments, this commit try to
elminate #ifdef from the body of the code if possible.
We check the flags to determine whether enable GLAMOR
at runtime, rather than check the MACRO during the compile
time.
Signed-off-by: Zhigang Gong
---
src/intel_driver.c |
As uxa_driver may be released before the last call to freeScreen
and destroy the last pixmap, we have to introduce a new flag in
intel structure to indicate whether we are using GLAMOR. This
intel->uxa_flag is a clone of intel->uxa_driver->flags element.
Signed-off-by: Zhigang Gong
do
the rendering. If the UXA_USE_GLAMOR_ONLY is set, it then
jump to fallback path directly and avoid the UXA acceleration
code.
Signed-off-by: Zhigang Gong
---
uxa/uxa.h | 16
1 files changed, 16 insertions(+), 0 deletions(-)
diff --git a/uxa/uxa.h b/uxa/uxa.h
index e001c53
> -Original Message-
> From: Chris Wilson [mailto:ch...@chris-wilson.co.uk]
> Sent: Monday, November 14, 2011 5:07 PM
> To: Zhigang Gong; intel-gfx@lists.freedesktop.org
> Subject: RE: [Intel-gfx] [PATCH 2/3] glamor: turn on glamor.
>
> On Mon, 14 Nov 2011 13:01:36
If GLAMOR is enabled, we route UXA's fillspans and
polyfillrects to glamor by default. And if glamor
fail to accelerate it, UXA continue to handle it.
Reviewed-by: Eugeni Dodonov
Signed-off-by: Zhigang Gong
---
uxa/uxa-accel.c | 13 -
1 files changed, 12 insertions(
has a valid BO can get a cooresponding texture.
After this commit. It's ready to do rendering through
glamor's rendering functions.
Reviewed-by: Eugeni Dodonov
Signed-off-by: Zhigang Gong
---
src/intel_driver.c | 26 +-
src/intel_uxa.c| 25 +
e
configuration.
Reviewed-by: Eugeni Dodonov
Signed-off-by: Zhigang Gong
---
configure.ac | 17 +++
src/Makefile.am|5 ++
src/intel_glamor.c | 130
src/intel_glamor.h | 45 ++
4 files changed, 197 insertions(
Thanks for the review. Fixed that empty #ifdef block, missed one line code
there to free glamor screen.
From: eugeni.dodo...@gmail.com [mailto:eugeni.dodo...@gmail.com] On Behalf
Of Eugeni Dodonov
Sent: Friday, November 11, 2011 8:59 PM
To: Zhigang Gong
Cc: intel-gfx@lists.freedesktop.org
> -Original Message-
> From: Jamey Sharp [mailto:ja...@minilop.net]
> Sent: Saturday, November 12, 2011 5:47 AM
> To: Zhigang Gong
> Cc: xorg-de...@lists.x.org; intel-gfx@lists.freedesktop.org
> Subject: Re: Glamor update
>
> Hello!
>
> On Fri, Nov 11, 201
> -Original Message-
> From: Chris Wilson [mailto:ch...@chris-wilson.co.uk]
> Sent: Friday, November 11, 2011 9:13 PM
> To: Zhigang Gong; intel-gfx@lists.freedesktop.org
> Subject: RE: [Intel-gfx] [PATCH 2/3] glamor: turn on glamor.
>
> On Fri, 11 Nov 2011 18:52:11
> -Original Message-
> From: Chris Wilson [mailto:ch...@chris-wilson.co.uk]
> Sent: Friday, November 11, 2011 9:55 PM
> To: Zhigang Gong; intel-gfx@lists.freedesktop.org
> Subject: RE: [Intel-gfx] [PATCH 3/3] glamor: Route fillspans and
polyfillrects
> to glamor.
>
> -Original Message-
> From: Chris Wilson [mailto:ch...@chris-wilson.co.uk]
> Sent: Friday, November 11, 2011 5:12 PM
> To: Zhigang Gong; intel-gfx@lists.freedesktop.org
> Subject: Re: [Intel-gfx] [PATCH 2/3] glamor: turn on glamor.
>
> On Fri, 11 Nov 2011 16:31:2
> -Original Message-
> From: Chris Wilson [mailto:ch...@chris-wilson.co.uk]
> Sent: Friday, November 11, 2011 5:08 PM
> To: Zhigang Gong; intel-gfx@lists.freedesktop.org
> Subject: Re: [Intel-gfx] [PATCH 3/3] glamor: Route fillspans and
polyfillrects
> to glamor.
>
If GLAMOR is enabled, we route UXA's fillspans and
polyfillrects to glamor by default. And if glamor
fail to accelerate it, UXA continue to handle it.
Signed-off-by: Zhigang Gong
---
uxa/uxa-accel.c | 13 -
1 files changed, 12 insertions(+), 1 deletions(-)
diff --git a/ux
has a valid BO can get a cooresponding texture.
After this commit. It's ready to do rendering through
glamor's rendering functions.
Signed-off-by: Zhigang Gong
---
src/intel_driver.c | 25 -
src/intel_uxa.c| 22 +-
2 files cha
e
configuration.
Signed-off-by: Zhigang Gong
---
configure.ac | 17 +++
src/Makefile.am|5 ++
src/intel_glamor.c | 130
src/intel_glamor.h | 45 ++
4 files changed, 197 insertions(+), 0 deletions(-)
create
Hi folks，
During the last discussion about glamor’s plan in this list, we got a
conclusion that to extract glamor from xorg and
build a separate glamor library to be used by any possible DDX driver. And
Eric suggested I can incrementally
merge glamor into Intel video driver. Now here is the
N/A 15.3s
On Wed, Aug 17, 2011 at 8:18 PM, zhigang gong wrote:
> Hi folks,
>
> Glamor project was initiated by Eric at last year which is to implement a new
> rendering acceleration engine by using OpenGL to handle all the 2D operations.
> It is somehow very similar with UXA. The
Hi folks,
Glamor project was initiated by Eric at last year which is to implement a new
rendering acceleration engine by using OpenGL to handle all the 2D operations.
It is somehow very similar with UXA. The major difference is that we use texture
to hold pixmap if possible, and then use shaders
Current EGL only support one drm buffer format which is
EGL_DRM_BUFFER_FORMAT_ARGB32_MESA. This
format works fine with normal image, but if we want to
create a drm buffer which will be used for a hardware cursor,
then it has problem. The default behaviou for this format is
87 matches
Mail list logo
