On 05/03/2013 10:44 AM, Chia-I Wu wrote:
It can be selected with
BOARD_GPU_DRIVERS := ilo
Signed-off-by: Chia-I Wu
Reviewed-by: Tapani Pälli
---
Android.mk|4 +--
src/egl/main/Android.mk |6 +
src/gallium/Android.mk
On 05/03/2013 10:44 AM, Chia-I Wu wrote:
Add libsync not only for MESA_BUILD_CLASSIC, but also for MESA_BUILD_GALLIUM.
Signed-off-by: Chia-I Wu
Reviewed-by: Tapani Pälli
---
src/egl/main/Android.mk |8 +++-
1 file changed, 3 insertions(+), 5 deletions(-)
diff --git a/src/egl/ma
Am 05.05.2013 18:34, schrieb Chia-I Wu:
> It should be TGSI_TYPE_UNSIGNED, not TGSI_TYPE_FLOAT.
>
> Fixed also gallivm not_emit_cpu() to use uint build context.
>
> Signed-off-by: Chia-I Wu
> ---
> src/gallium/auxiliary/gallivm/lp_bld_tgsi_action.c |2 +-
> src/gallium/auxiliary/tgsi/tgsi_i
Hi,
I am trying to build s/w only mesa driver. It seems that the
performance of software only renderer (compiled with
--with-driver=xlib) is higher than that of h/w drivers. Could someone
please help me understand what is causing this or if it is expected?
I see that dri based s/w renderer is
I don't think glxgears is the best benchmark for what is a "typical" OpenGL
load (if there is a "typical"). The 60 FPS with your hardware driver sounds
suspiciously like the refresh rate of your screen; perhaps it is
synchronized with the vertical retrace? Since I'm assuming you want to find
the fa
On Mon, May 6, 2013 at 10:33 AM, Divick Kishore
wrote:
> Hi,
> I am trying to build s/w only mesa driver. It seems that the
> performance of software only renderer (compiled with
> --with-driver=xlib) is higher than that of h/w drivers. Could someone
> please help me understand what is causin
On Mon, May 6, 2013 at 8:08 PM, Patrick Baggett
wrote:
> I don't think glxgears is the best benchmark for what is a "typical" OpenGL
> load (if there is a "typical"). The 60 FPS with your hardware driver sounds
> suspiciously like the refresh rate of your screen; perhaps it is
> synchronized with
> The default is to sync to the refresh rate. Try setting env var
> vblank_mode=0 to disable it.
>
Indeed with this, I see that the performance jumps to almost ~ 3850
fps. Thanks for pointing this out.
Thanks & Regards,
Divick
___
mesa-dev mailing list
On Sat, May 04, 2013 at 09:09:25AM -0700, Vincent Lejeune wrote:
> Hi,
>
> Thank for doing this.
> Patches 1 2 and 3 have my rb.
> For patch 4:
>
Hi Vincent,
Attached is an updated version of patch 4.
-Tom
> >@@ -125,9 +106,7 @@ MCCodeEmitter *llvm::createR600MCCodeEmitter(const
> >MCInstrIn
On Mon, 6 May 2013 20:20:52 +0530
Divick Kishore wrote:
> > The default is to sync to the refresh rate. Try setting env var
> > vblank_mode=0 to disable it.
> >
>
> Indeed with this, I see that the performance jumps to almost ~ 3850
> fps. Thanks for pointing this out.
Doesn't your glxgears te
Currently the i965 driver uses a single buffer object to hold both batch
buffer commands and dynamic state data structures (which are pointed to by
batch buffer commands). We use a "stack and heap model", where the former
are allocated from the front end of the bo and the latter are allocated
from
On Sun, May 05, 2013 at 09:26:42PM -0700, Matt Turner wrote:
> On Sun, May 5, 2013 at 8:53 PM, Chad Versace
> wrote:
> > On 05/04/2013 03:20 PM, Matt Turner wrote:
> >>
> >> On Sat, May 4, 2013 at 12:14 AM, Matt Turner wrote:
> >>>
> >>> On Fri, May 3, 2013 at 10:42 PM, Chad Versace
> >>> wrote:
AFAICT these new patterns and intrinsics should be sufficient for full
GLSL 1.30 support in radeonsi.
I suspect these will need some polishing, but I wanted to send them out
now for initial comments so they can hopefully make it into the LLVM 3.3
release.
--
Earthling Michel Dänzer |
On Mon, May 06, 2013 at 06:23:05PM +0200, Michel Dänzer wrote:
>
> AFAICT these new patterns and intrinsics should be sufficient for full
> GLSL 1.30 support in radeonsi.
>
> I suspect these will need some polishing, but I wanted to send them out
> now for initial comments so they can hopefully m
On 05/06/2013 10:09 AM, Tom Stellard wrote:
Module: Mesa
Branch: master
Commit: 55eb8eaaa8bf8696d56effce6ed87f03bea779e0
URL:
http://cgit.freedesktop.org/mesa/mesa/commit/?id=55eb8eaaa8bf8696d56effce6ed87f03bea779e0
Author: Tom Stellard
Date: Tue Apr 30 07:38:03 2013 -0700
gallivm: Move L
From: Tom Stellard
The BFE optimization was the only one we were actually using, and it was
emitting an intrinsic that we don't support.
https://bugs.freedesktop.org/show_bug.cgi?id=64201
---
lib/Target/R600/AMDGPUInstructions.td | 11 +
lib/Target/R600/AMDGPUTargetMachine.cpp|1
On Mon, May 06, 2013 at 10:44:46AM -0600, Brian Paul wrote:
> On 05/06/2013 10:09 AM, Tom Stellard wrote:
> >Module: Mesa
> >Branch: master
> >Commit: 55eb8eaaa8bf8696d56effce6ed87f03bea779e0
> >URL:
> >http://cgit.freedesktop.org/mesa/mesa/commit/?id=55eb8eaaa8bf8696d56effce6ed87f03bea779e0
>
On 05/05/2013 04:50 PM, Kenneth Graunke wrote:
On 05/03/2013 04:07 PM, Ian Romanick wrote:
From: Ian Romanick
Lower ir_binop_vector_extract with a constant index to a swizzle. This
is exactly like ir_dereference_array of a vector with a constant index.
v2: Convert tabs to spaces. Suggested
On Mon, May 06, 2013 at 09:51:31AM -0700, Tom Stellard wrote:
> On Mon, May 06, 2013 at 10:44:46AM -0600, Brian Paul wrote:
> > On 05/06/2013 10:09 AM, Tom Stellard wrote:
> > >Module: Mesa
> > >Branch: master
> > >Commit: 55eb8eaaa8bf8696d56effce6ed87f03bea779e0
> > >URL:
> > >http://cgit.free
Reviewed-by:Vincent Lejeune
- Mail original -
> De : Tom Stellard
> À : Vincent Lejeune
> Cc : "llvm-comm...@cs.uiuc.edu" ;
> "mesa-dev@lists.freedesktop.org"
> Envoyé le : Lundi 6 mai 2013 17h02
> Objet : Re: R600 Patchset: Emit true ISA
>
> On Sat, May 04, 2013 at 09:09:25AM -0700,
Hi Patrick,
thanks for the reply. Could you guide me on how to
build llvmpipe driver?
Thanks & Regards,
Divick
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
On 05/06/2013 07:15 PM, Divick Kishore wrote:
Hi Patrick,
thanks for the reply. Could you guide me on how to
build llvmpipe driver?
Thanks & Regards,
Divick
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedes
On 05/06/2013 11:02 AM, Tom Stellard wrote:
On Mon, May 06, 2013 at 09:51:31AM -0700, Tom Stellard wrote:
On Mon, May 06, 2013 at 10:44:46AM -0600, Brian Paul wrote:
On 05/06/2013 10:09 AM, Tom Stellard wrote:
Module: Mesa
Branch: master
Commit: 55eb8eaaa8bf8696d56effce6ed87f03bea779e0
URL:
Bugzilla: https://bugs.gentoo.org/show_bug.cgi?id=461696
---
src/gallium/targets/dri-i915/Makefile.am | 10 ++
1 file changed, 2 insertions(+), 8 deletions(-)
diff --git a/src/gallium/targets/dri-i915/Makefile.am
b/src/gallium/targets/dri-i915/Makefile.am
index f4f9030..ce6be78 100644
--
On 3 May 2013 16:07, Ian Romanick wrote:
> From: Ian Romanick
>
> Right now the lower_clip_distance_visitor lowers variable indexing into
> gl_ClipDistance into variable indexing into both the array
> gl_ClipDistanceMESA and the vectors of that array. For example,
>
> gl_ClipDistance[i] = f
2013/5/6 Chí-Thanh Christopher Nguyễn
> Bugzilla: https://bugs.gentoo.org/show_bug.cgi?id=461696
>
NOTE: This is a candidate for the 9.1 branch.
Reviewed-by: Andreas Boll
---
> src/gallium/targets/dri-i915/Makefile.am | 10 ++
> 1 file changed, 2 insertions(+), 8 deletions(-)
>
> di
On 05/06/2013 11:35 AM, Paul Berry wrote:
On 3 May 2013 16:07, Ian Romanick mailto:i...@freedesktop.org>> wrote:
From: Ian Romanick mailto:ian.d.roman...@intel.com>>
Right now the lower_clip_distance_visitor lowers variable indexing into
gl_ClipDistance into variable indexing into b
Paul Berry writes:
> Currently the i965 driver uses a single buffer object to hold both batch
> buffer commands and dynamic state data structures (which are pointed to by
> batch buffer commands). We use a "stack and heap model", where the former
> are allocated from the front end of the bo and
Commit 62452883 removed a hunk like
if (firstImageFormat != stObj->pt->format)
st_view_format = firstImageFormat;
from update_single_texture(). This broke piglit/glx-tfp on AMD Barts
(and probably others), as that hunk was compensating for the mesa and
gallium layers disagreeing abou
>> What do you think?
>
> It would need some sort of plan for how to deal with making
> drm_intel_bufmgr_check_aperture work correctly and efficiently when a
> reloced-to BO gets new relocs, which is the reason everything is in one
> BO currently.
I was looking for code that did this for something
Emit EGL_BAD_CONTEXT if the user passes a context to
eglCreateImageKHR(type=EGL_ANDROID_image_native_buffer).
From the EGL_ANDROID_image_native_buffer spec:
* If is EGL_NATIVE_BUFFER_ANDROID and is not
EGL_NO_CONTEXT, the error EGL_BAD_CONTEXT is generated.
Note: This is a candidate for t
Kenneth Graunke writes:
> On 04/30/2013 12:56 PM, Eric Anholt wrote:
>> Everyone was doing effectively the same thing, except for some funky code
>> reuse in Intel, and swrast mistakenly recomputing _BaseFormat instead of
>> using the texture's _BaseFormat. swrast's sRGB handling is left in plac
On 05/06/2013 02:32 PM, Eric Anholt wrote:
Kenneth Graunke writes:
On 04/30/2013 12:56 PM, Eric Anholt wrote:
Everyone was doing effectively the same thing, except for some funky code
reuse in Intel, and swrast mistakenly recomputing _BaseFormat instead of
using the texture's _BaseFormat. sw
On Wed, May 1, 2013 at 2:10 PM, Anuj Phogat wrote:
> In traditional multisampled framebuffer rendering, color samples must be
> explicitly
> resolved via BlitFramebuffer before doing the scaled blitting of the
> framebuffer.
> So, scaled blitting of a multisample framebuffer takes two separate c
On Mon, May 06, 2013 at 09:30:58AM -0700, Tom Stellard wrote:
> On Mon, May 06, 2013 at 06:23:05PM +0200, Michel Dänzer wrote:
> >
> > AFAICT these new patterns and intrinsics should be sufficient for full
> > GLSL 1.30 support in radeonsi.
> >
> > I suspect these will need some polishing, but I
Fixes a regression in firefox's ReadScreenIntoImageSurface ->
glReadPixels() path with the introduction of Y tiling.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=64213
---
src/mesa/drivers/dri/intel/intel_mipmap_tree.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git
We accidentally "fixed" the piglit test for this when introducing Y
tiling, since this path stopped being executed. In reenabling this path
for Y tiling, we ended up regressing it again, so just fix it.
---
src/mesa/drivers/dri/intel/intel_pixel_copy.c | 3 +++
1 file changed, 3 insertions(+)
di
---
src/mesa/drivers/dri/intel/intel_blit.c | 39 ++---
src/mesa/drivers/dri/intel/intel_reg.h | 6 +
2 files changed, 42 insertions(+), 3 deletions(-)
diff --git a/src/mesa/drivers/dri/intel/intel_blit.c
b/src/mesa/drivers/dri/intel/intel_blit.c
index 1f3fad5..
These two patches fix a number of piglit OpenCL test failures on my
HD6850 (Barts).
There are no piglit CL test regressions and the llvm make check runs
without any unexpected failures.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lis
Signed-off-by: Aaron Watry
---
lib/Target/R600/R600ISelLowering.cpp |3 +++
1 file changed, 3 insertions(+)
diff --git a/lib/Target/R600/R600ISelLowering.cpp
b/lib/Target/R600/R600ISelLowering.cpp
index c6e2136..6dec4d1 100644
--- a/lib/Target/R600/R600ISelLowering.cpp
+++ b/lib/Target/R600
Signed-off-by: Aaron Watry
---
lib/Target/R600/R600ISelLowering.cpp |2 ++
1 file changed, 2 insertions(+)
diff --git a/lib/Target/R600/R600ISelLowering.cpp
b/lib/Target/R600/R600ISelLowering.cpp
index 6dec4d1..ac56ed8 100644
--- a/lib/Target/R600/R600ISelLowering.cpp
+++ b/lib/Target/R600/
Ever since fake front was introduced in
63b51b5cf17ddde09b72a2811296f37b9a4c5ad2, we were skipping the XSync() in
the non-fake-front path, so compositors like Firefox's GL canvas were
having to manually put it in outside of glXWaitX().
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=52930
-
We were only flushing it in the fake-front case, which won't be enough if
you're doing something like drawing into a GLXPixmap and using X rendering
to composite from it.
---
src/glx/dri2_glx.c | 28
1 file changed, 24 insertions(+), 4 deletions(-)
diff --git a/src/gl
On Mon, May 06, 2013 at 07:35:42PM -0500, Aaron Watry wrote:
> These two patches fix a number of piglit OpenCL test failures on my
> HD6850 (Barts).
>
> There are no piglit CL test regressions and the llvm make check runs
> without any unexpected failures.
>
Hi Aaron,
These patches look good to
The constant packets for gen6 are too small for gen7, and while IVB seems
happy with them HSW blows up. Just restore the HSW path to what it was
before the gen6 change, by making gen7-specific functions to set up these
stages.
---
The alternative here would be to emit the correct lengths of packe
On Mon, May 6, 2013 at 3:51 AM, Vinson Lee wrote:
> Fixes "Missing break in switch" defect reported by Coverity.
>
> Signed-off-by: Vinson Lee
Applied. Thanks.
> ---
> src/gallium/drivers/ilo/shader/toy_tgsi.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/src/gallium/drivers/ilo/shad
Eric Anholt writes:
> The constant packets for gen6 are too small for gen7, and while IVB seems
> happy with them HSW blows up. Just restore the HSW path to what it was
> before the gen6 change, by making gen7-specific functions to set up these
> stages.
Of course, this needs the NOTE for stabl
On Mon, May 6, 2013 at 6:45 PM, Roland Scheidegger wrote:
> Am 05.05.2013 18:34, schrieb Chia-I Wu:
>> It should be TGSI_TYPE_UNSIGNED, not TGSI_TYPE_FLOAT.
>>
>> Fixed also gallivm not_emit_cpu() to use uint build context.
>>
>> Signed-off-by: Chia-I Wu
>> ---
>> src/gallium/auxiliary/gallivm/l
Hi,
is there a possibility in mesa to have egl backend based on
complete offscreen buffers and complete s/w only gles renderer? If
yes, then could someone please guide me how to build it?
Thanks & Regards,
Divick
___
mesa-dev mailing list
mesa-dev@li
On 05/06/2013 04:41 PM, Eric Anholt wrote:
Fixes a regression in firefox's ReadScreenIntoImageSurface ->
glReadPixels() path with the introduction of Y tiling.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=64213
---
src/mesa/drivers/dri/intel/intel_mipmap_tree.c | 3 ++-
1 file chang
On 05/06/2013 09:02 PM, Eric Anholt wrote:
The constant packets for gen6 are too small for gen7, and while IVB seems
happy with them HSW blows up. Just restore the HSW path to what it was
before the gen6 change, by making gen7-specific functions to set up these
stages.
---
The alternative here
On 05/03/2013 04:07 PM, Ian Romanick wrote:
From: Ian Romanick
This will eventually replace do_vec_index_to_cond_assign. This lowering
pass is called in all the places where do_vec_index_to_cond_assign or
do_vec_index_to_swizzle is called.
v2: Use WRITEMASK_* instead of integer literals. Use
52 matches
Mail list logo