Making all in builtin_compiler
gmake[4]: Entering directory `/opt/mesa/src/glsl/builtin_compiler'
CXX glsl_lexer.lo
glsl_lexer.cpp: In function 'int yy_get_next_buffer(yyscan_t)':
glsl_lexer.cpp:3076:3: warning: comparison between signed and unsigned
integer expressions [-Wsign-compare]
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 olva...@gmail.com
Reviewed-by: Tapani Pälli tapani.pa...@intel.com
---
Android.mk|4 +--
src/egl/main/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 olva...@gmail.com
Reviewed-by: Tapani Pälli tapani.pa...@intel.com
---
src/egl/main/Android.mk |8 +++-
1 file changed, 3 insertions(+),
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 olva...@gmail.com
---
src/gallium/auxiliary/gallivm/lp_bld_tgsi_action.c |2 +-
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
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
On Mon, May 6, 2013 at 10:33 AM, Divick Kishore
divick.kish...@gmail.com 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
On Mon, May 6, 2013 at 8:08 PM, Patrick Baggett
baggett.patr...@gmail.com 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
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
MCInstrInfo MCII,
On Mon, 6 May 2013 20:20:52 +0530
Divick Kishore divick.kish...@gmail.com 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
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
chad.vers...@linux.intel.com wrote:
On 05/04/2013 03:20 PM, Matt Turner wrote:
On Sat, May 4, 2013 at 12:14 AM, Matt Turner matts...@gmail.com wrote:
On Fri, May 3, 2013 at 10:42
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 make
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 Stellardthomas.stell...@amd.com
Date: Tue Apr 30 07:38:03
From: Tom Stellard thomas.stell...@amd.com
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 +
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
Author:
On 05/05/2013 04:50 PM, Kenneth Graunke wrote:
On 05/03/2013 04:07 PM, Ian Romanick wrote:
From: Ian Romanick ian.d.roman...@intel.com
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
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:
Reviewed-by:Vincent Lejeunevljn at ovi.com
- Mail original -
De : Tom Stellard t...@stellard.net
À : Vincent Lejeune v...@ovi.com
Cc : llvm-comm...@cs.uiuc.edu llvm-comm...@cs.uiuc.edu;
mesa-dev@lists.freedesktop.org mesa-dev@lists.freedesktop.org
Envoyé le : Lundi 6 mai 2013 17h02
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
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 i...@freedesktop.org wrote:
From: Ian Romanick ian.d.roman...@intel.com
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
2013/5/6 Chí-Thanh Christopher Nguyễn chith...@gentoo.org
Bugzilla: https://bugs.gentoo.org/show_bug.cgi?id=461696
NOTE: This is a candidate for the 9.1 branch.
Reviewed-by: Andreas Boll andreas.boll@gmail.com
---
src/gallium/targets/dri-i915/Makefile.am | 10 ++
1 file
On 05/06/2013 11:35 AM, Paul Berry wrote:
On 3 May 2013 16:07, Ian Romanick i...@freedesktop.org
mailto:i...@freedesktop.org wrote:
From: Ian Romanick ian.d.roman...@intel.com
mailto:ian.d.roman...@intel.com
Right now the lower_clip_distance_visitor lowers variable indexing into
Paul Berry stereotype...@gmail.com 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
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 about
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 target is EGL_NATIVE_BUFFER_ANDROID and ctx is not
EGL_NO_CONTEXT, the error EGL_BAD_CONTEXT is generated.
Note: This is a
Kenneth Graunke kenn...@whitecape.org 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
On 05/06/2013 02:32 PM, Eric Anholt wrote:
Kenneth Graunke kenn...@whitecape.org 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
On Wed, May 1, 2013 at 2:10 PM, Anuj Phogat anuj.pho...@gmail.com 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
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 wanted to
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(+)
---
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
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
Signed-off-by: Aaron Watry awa...@gmail.com
---
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
+++
Signed-off-by: Aaron Watry awa...@gmail.com
---
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
+++
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
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 me,
45 matches
Mail list logo
