Hi Jakob,
Unfortunately ARB_clear_texture is not as straight forward and taking
that from nouveau.
You will notice I sent essentially a identical series last year to the
ml as a rfc. You
can find that work sitting around on my github here:
https://github.com/victoredwardocallaghan/mesa-GLwor
On 16.04.2016 14:51, Michel Dänzer wrote:
> On 16.04.2016 11:39, Tom Stellard wrote:
>> The ds_bpermute instruction allows threads to transfer data directly
>> to or from the vgprs of other threads. These instructions use the lds
>> hardware to transfer data, but do not read or write lds memory.
>
On 16.04.2016 11:39, Tom Stellard wrote:
> The ds_bpermute instruction allows threads to transfer data directly
> to or from the vgprs of other threads. These instructions use the lds
> hardware to transfer data, but do not read or write lds memory.
>
> DDX BEFORE:| DDX A
https://bugs.freedesktop.org/show_bug.cgi?id=94955
Roland Scheidegger changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
The ds_bpermute instruction allows threads to transfer data directly
to or from the vgprs of other threads. These instructions use the lds
hardware to transfer data, but do not read or write lds memory.
DDX BEFORE:| DDX AFTER:
|
v_mbcnt_
Reviewed-by: Charmaine Lee
From: Brian Paul
Sent: Friday, April 15, 2016 2:41 PM
To: mesa-dev@lists.freedesktop.org
Cc: Charmaine Lee
Subject: [PATCH] svga: separate HUD counters for state objects
Count depth/stencil, blend, sampler, etc. state objects s
We're trying to move to more of the new style intrinsics with include
the correct target name, and map directly to ISA instructions.
---
src/gallium/drivers/radeonsi/si_shader.c | 12 ++--
1 file changed, 10 insertions(+), 2 deletions(-)
diff --git a/src/gallium/drivers/radeonsi/si_shader
https://bugs.freedesktop.org/show_bug.cgi?id=94168
Grazvydas Ignotas changed:
What|Removed |Added
CC||nota...@gmail.com
--
You are receiv
https://bugs.freedesktop.org/show_bug.cgi?id=94168
--- Comment #6 from Grazvydas Ignotas ---
I've put my HD 5770 in and can confirm r600g suffers from this too.
--
You are receiving this mail because:
You are the assignee for the bug.
You are the QA Contact for the bug._
This is mostly for variables that are only used in asserts and cause
unused-but-set-variable warnings in release builds. Could just use
UNUSED directly, but MAYBE_UNUSED should be less confusing and is
similar to what the Linux kernel has.
And yes __attribute__((unused)) can be used on variables o
Mark variables MAYBE_UNUSED to avoid unused-but-set-variable warnings
in release build.
Signed-off-by: Grazvydas Ignotas
---
I have no commit access, if this patch is ok, please someone push.
src/gallium/auxiliary/pipebuffer/pb_buffer_fenced.c | 2 +-
src/gallium/auxiliary/util/u_surface.c
Mark variables MAYBE_UNUSED to avoid unused-but-set-variable warnings
in release build.
Signed-off-by: Grazvydas Ignotas
---
I have no commit access, if this patch is ok, please someone push.
src/intel/vulkan/anv_dump.c | 2 +-
src/intel/vulkan/anv_image.c
I guess almost everyone here builds mesa with asserts enabled, but many
forget asserts are off by default, so ordinary users get thrown at quite
a lot of warnings. This tries to improve the situation somewhat.
Grazvydas Ignotas (7):
util: add MAYBE_UNUSED for config dependent variables
glsl: f
Mark variable MAYBE_UNUSED to avoid unused-but-set-variable warning in
release build.
Signed-off-by: Grazvydas Ignotas
---
I have no commit access, if this patch is ok, please someone push.
src/compiler/spirv/vtn_cfg.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/comp
Mark variables MAYBE_UNUSED to avoid unused-but-set-variable warnings
in release build.
Signed-off-by: Grazvydas Ignotas
---
I have no commit access, if this patch is ok, please someone push.
src/intel/isl/isl.c | 2 +-
src/intel/isl/isl_gen7.c | 2 +-
2 files changed, 2 insertions(+), 2 d
Mark variable MAYBE_UNUSED to avoid unused-but-set-variable warning in
release build.
Signed-off-by: Grazvydas Ignotas
---
I have no commit access, if this patch is ok, please someone push.
src/compiler/glsl/lower_buffer_access.cpp | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --g
Avoids warnings in release builds.
Signed-off-by: Grazvydas Ignotas
---
I have no commit access, if this patch is ok, please someone push.
src/gallium/auxiliary/gallivm/lp_bld_intr.c | 2 +-
src/gallium/drivers/radeon/radeon_llvm_emit.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
Francisco Jerez writes:
> Jason Ekstrand writes:
>
>> We have had a guard against OOB array access of images on IVB for a long
>> time, but it can actually cause hangs on any GPU generation. This can
>> happen due to getting an untyped SURFACE_STATE for a typed message or
>> vice-versa.
>
> Are
https://bugs.freedesktop.org/show_bug.cgi?id=94957
--- Comment #4 from Roland Scheidegger ---
(In reply to Ilia Mirkin from comment #3)
> I will start a fresh run with these parameters. A random blending test makes
> it seem like it completely fails. I'd like to encourage you to grab a copy
> of
https://bugs.freedesktop.org/show_bug.cgi?id=94955
--- Comment #5 from Roland Scheidegger ---
(In reply to Roland Scheidegger from comment #4)
> I actually tried to give the replay a look, but the problem is that so far
> I've always failed to get apitrace + valgrind + gdb to work. The problem is
https://bugs.freedesktop.org/show_bug.cgi?id=94957
--- Comment #3 from Ilia Mirkin ---
A random sampling of the texturing tests that failed seem to all pass with
GALLIVM_DEBUG=no_rho_approx,no_brilinear,no_quad_lod
I will start a fresh run with these parameters. A random blending test makes it
Reviewed-by: Bas Nieuwenhuizen
On Sat, Apr 16, 2016 at 2:13 AM, Marek Olšák wrote:
> From: Marek Olšák
>
> ---
> src/gallium/auxiliary/util/u_math.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/src/gallium/auxiliary/util/u_math.h
> b/src/gallium/auxiliary/util/u_ma
On Fri, Apr 15, 2016 at 7:50 PM, Grigori Goronzy wrote:
> Small IBs help to reduce stalls for workloads that require a lot of
> synchronization. On the other hand, if there is no notable
> synchronization, we can use a large IB size to slightly improve
> performance in some cases.
>
> This introdu
https://bugs.freedesktop.org/show_bug.cgi?id=94957
--- Comment #2 from Roland Scheidegger ---
Oh, linear mipmap filtering should work perfectly. For performance reasons
though we cheat, which is likely why it fails.
The cheats can be disabled via env var, preferably all 3 of them
(GALLIVM_DEBUG=n
Jason Ekstrand writes:
> We have had a guard against OOB array access of images on IVB for a long
> time, but it can actually cause hangs on any GPU generation. This can
> happen due to getting an untyped SURFACE_STATE for a typed message or
> vice-versa.
Are you sure about that? AFAIK the
"ar
https://bugs.freedesktop.org/show_bug.cgi?id=94955
--- Comment #4 from Roland Scheidegger ---
(In reply to Roland Scheidegger from comment #2)
> > > ==32054== Conditional jump or move depends on uninitialised value(s)
> > > ==32054==at 0x404002D: ???
> > > ==32054==by 0x5415736: lp_rast_s
https://bugs.freedesktop.org/show_bug.cgi?id=94955
--- Comment #3 from Emil Velikov ---
(In reply to David Lonie from comment #0)
> (Regular 'make install' does this in the install dir for some reason:
>
> $ ls mesa-master-install/lib/libMesaGL.so* -lh
>
> mesa-ma
From: Marek Olšák
---
src/gallium/auxiliary/util/u_math.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/gallium/auxiliary/util/u_math.h
b/src/gallium/auxiliary/util/u_math.h
index 0a82915..d983af3 100644
--- a/src/gallium/auxiliary/util/u_math.h
+++ b/src/gallium/auxil
On 15 April 2016 at 22:11, Grazvydas Ignotas wrote:
> On Fri, Apr 15, 2016 at 9:46 PM, Christian Schmidbauer
> wrote:
>> On 15/04/16 17:06, Emil Velikov wrote:
>>> From: Emil Velikov
>>>
>>> The __i386__ and __x86-64__ macros are gcc/clang specific, thus one does
>>> not need the __GNUC__ at the
On Sat, Apr 16, 2016 at 12:40 AM, Bas Nieuwenhuizen
wrote:
> On Sat, Apr 16, 2016 at 12:34 AM, Marek Olšák wrote:
>> From: Marek Olšák
>>
>> The second ffs returns 0, yielding count == -1.
>> ---
>> src/gallium/auxiliary/util/u_math.h | 6 ++
>> 1 file changed, 6 insertions(+)
>>
>> diff --
On 15 April 2016 at 19:58, Chuck Atkins wrote:
> On Fri, Apr 15, 2016 at 2:07 PM, Emil Velikov
> wrote:
>>
>> On 15 April 2016 at 16:36, Chuck Atkins wrote:
>> > Instead of cascading support for various different implementations of
>> > GLX, all three options are now specified through the --enab
https://bugs.freedesktop.org/show_bug.cgi?id=94957
--- Comment #1 from Ilia Mirkin ---
This was, by the way, the result of running mesa master with
LIBGL_ALWAYS_SOFTWARE=1 ./deqp-gles3 --deqp-visibility=hidden
--deqp-caselist-file=<(grep -v 'mipmap_linear'
../../android/cts/master/gles3-master.t
https://bugs.freedesktop.org/show_bug.cgi?id=94957
Bug ID: 94957
Summary: dEQP failures on llvmpipe
Product: Mesa
Version: unspecified
Hardware: Other
OS: All
Status: NEW
Severity: normal
Priorit
On Fri, Apr 15, 2016 at 12:01 PM, Michel Dänzer wrote:
> On 14.04.2016 21:18, Oded Gabbay wrote:
>> Add a helper function which receives pipe_format value and returns a
>> matching pipe_endian value. It is needed because almost every call to
>> st_create_texture will use this function to send the
For patches 1-2:
Reviewed-by: Marek Olšák
Feel free to push those two.
Marek
On Thu, Apr 14, 2016 at 2:18 PM, Oded Gabbay wrote:
> I need to do this so I could use R600_BIG_ENDIAN in files which include
> r600_pipe_common.h but not r600_pipe.h
>
> Signed-off-by: Oded Gabbay
> ---
> src/gall
For ctags users like me.
Signed-off-by: Grazvydas Ignotas
---
I have no commit access, if this patch is ok, please someone push.
.gitignore | 1 +
1 file changed, 1 insertion(+)
diff --git a/.gitignore b/.gitignore
index b4f88f7..7db5639 100644
--- a/.gitignore
+++ b/.gitignore
@@ -34,6 +34,7
Reviewed-by: Axel Davy
On 16/04/2016 00:44, Marek Olšák wrote:
From: Marek Olšák
just need to do the calculation in floating-point and then round things
properly
---
src/gallium/drivers/radeon/r600_viewport.c | 36 +-
1 file changed, 21 insertions(+), 15 deletio
From: Marek Olšák
just need to do the calculation in floating-point and then round things
properly
---
src/gallium/drivers/radeon/r600_viewport.c | 36 +-
1 file changed, 21 insertions(+), 15 deletions(-)
diff --git a/src/gallium/drivers/radeon/r600_viewport.c
b/src
Reviewed-by: Marek Olšák
Marek
On Fri, Apr 15, 2016 at 8:15 PM, Brian Paul wrote:
> To silence a valgrind uninitialized memory warning.
>
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=94955
> Cc: "11.1 11.2"
> ---
> src/gallium/auxiliary/util/u_blitter.c | 2 +-
> 1 file changed, 1
On Sat, Apr 16, 2016 at 12:34 AM, Marek Olšák wrote:
> From: Marek Olšák
>
> The second ffs returns 0, yielding count == -1.
> ---
> src/gallium/auxiliary/util/u_math.h | 6 ++
> 1 file changed, 6 insertions(+)
>
> diff --git a/src/gallium/auxiliary/util/u_math.h
> b/src/gallium/auxiliary/u
From: Marek Olšák
The second ffs returns 0, yielding count == -1.
---
src/gallium/auxiliary/util/u_math.h | 6 ++
1 file changed, 6 insertions(+)
diff --git a/src/gallium/auxiliary/util/u_math.h
b/src/gallium/auxiliary/util/u_math.h
index b4ac0db..2880eea 100644
--- a/src/gallium/auxiliary
I've commented on some of the patches, but the series is:
Reviewed-by: Marek Olšák
I'd still like to have the preamble CE IB (explained in 00/13)
implemented before this lands, so that context flushes are reasonably
fast. Only the closed GL driver has been using it so far.
Marek
On Thu, Apr 1
The patch seems unneeded, as a lot of nine apps with the disabled
clipping behaviour are working fine.
It seems the bug is with the scissor bound computation:
for power of two RT, nine is removing a small offset to the viewport for
radeon to workaround a raterizer
precision bug.
The scissor c
Count depth/stencil, blend, sampler, etc. state objects separately
but just report the sum for the HUD. This change lets us use gdb to
see the breakdown of state objects in more detail.
Also, count sampler views too.
---
src/gallium/drivers/svga/svga_context.h | 10 +-
src/gall
On Fri, Apr 15, 2016 at 9:46 PM, Christian Schmidbauer
wrote:
> On 15/04/16 17:06, Emil Velikov wrote:
>> From: Emil Velikov
>>
>> The __i386__ and __x86-64__ macros are gcc/clang specific, thus one does
>> not need the __GNUC__ at the top.
>>
>> Additionally, having _M_IX86 and _M_X64 in the sam
On 04/05/2016 12:30 PM, Jason Ekstrand wrote:
...
> If people step up with code review, I'm hoping that we can merge some
> time this week or next.
>
> --Jason Ekstrand
Woo! The Vulkan code is finally merged!
___
mesa-dev mailing list
mesa-dev@lists.f
Reviewed-by: Mark Janes
Jason Ekstrand writes:
> This adds functions for splicing one list into another. These have
> more-or-less the same API as the kernel list splicing functions.
> ---
> src/util/list.h | 22 ++
> 1 file changed, 22 insertions(+)
>
> diff --git a/src/u
> On Apr 15, 2016, at 1:30 PM, Ilia Mirkin wrote:
>
> Signed-off-by: Ilia Mirkin
> ---
> src/gallium/drivers/swr/.gitignore | 7 +++
> 1 file changed, 7 insertions(+)
> create mode 100644 src/gallium/drivers/swr/.gitignore
>
> diff --git a/src/gallium/drivers/swr/.gitignore
> b/src/gallium
On Thu, Apr 14, 2016 at 8:05 PM, Nicolai Hähnle wrote:
> On 13.04.2016 20:35, Bas Nieuwenhuizen wrote:
>>
>> For use by radeonsi.
>>
>> Signed-off-by: Bas Nieuwenhuizen
>> ---
>> src/gallium/auxiliary/util/u_math.h | 8
>> 1 file changed, 8 insertions(+)
>>
>> diff --git a/src/gallium
On 04/15/2016 01:22 PM, srol...@vmware.com wrote:
From: Roland Scheidegger
The blend code would do a conditional assignment based on it, causing valgrind
to complain. Since that variable was actually unused in this case, this
doesn't fix anything but the warning.
Bugzilla: https://bugs.freedes
https://bugs.freedesktop.org/show_bug.cgi?id=92850
--- Comment #60 from higu...@gmx.net ---
Created attachment 122976
--> https://bugs.freedesktop.org/attachment.cgi?id=122976&action=edit
apitrace using radeon
Using ubuntu 15.10 with oibaf PPA, we get the crash using the intel and the
radeon dr
Tested-by: Mark Janes
Jason Ekstrand writes:
> We have had a guard against OOB array access of images on IVB for a long
> time, but it can actually cause hangs on any GPU generation. This can
> happen due to getting an untyped SURFACE_STATE for a typed message or
> vice-versa. We didn't used
From: Roland Scheidegger
The blend code would do a conditional assignment based on it, causing valgrind
to complain. Since that variable was actually unused in this case, this
doesn't fix anything but the warning.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=94955
Cc: "11.1 11.2"
---
Reviewed-by: Mark Janes
Chad Versace writes:
> _mesa_libgcrypt_init() returns NULL, but its return type is void.
>
> Cc: Mark Janes
> ---
> src/util/mesa-sha1.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/src/util/mesa-sha1.c b/src/util/mesa-sha1.c
> index ca6b8
(Sorry about the bad line wraps in the first one)
Instead of cascading support for various different implementations of
GLX, all three options are now specified through the --enable-glx
option:
--enable-glx=dri : Enable the DRI-based GLX
--enable-glx=xlib : Enable the classic
Instead of cascading support for various different implementations of
GLX, all three options are now specified through the --enable-glx
option:
--enable-glx=dri : Enable the DRI-based GLX
--enable-glx=xlib : Enable the classic Xlib-based GLX
--enable-glx=gallium-xlib : Enabl
On Fri, Apr 15, 2016 at 2:07 PM, Emil Velikov
wrote:
> On 15 April 2016 at 16:36, Chuck Atkins wrote:
> > Instead of cascading support for various different implementations of
> > GLX, all three options are now specified through the --enable-glx
> > option:
> >
> Bth having the single switch loo
On Fri, Apr 15, 2016 at 12:30 PM, Emil Velikov wrote:
> On 14 April 2016 at 20:40, Rob Herring wrote:
>> A couple more Android build fixes after rebasing to the current tip.
>>
>> Android master builds are still a bit broken because makefiles get
>> processed by kati in a different order. To fix,
On 04/15/2016 12:44 PM, Emil Velikov wrote:
On 15 April 2016 at 19:28, Brian Paul wrote:
Having the top-level lib/ directory is definitely a convenience. But I'm
not sure I know what you're asking.
Hehe silly me. Let me try again.
Why do we have three different versions across the different
On 15/04/16 17:06, Emil Velikov wrote:
> From: Emil Velikov
>
> The __i386__ and __x86-64__ macros are gcc/clang specific, thus one does
> not need the __GNUC__ at the top.
>
> Additionally, having _M_IX86 and _M_X64 in the same block (and even use
> __attribute__(foo)) is wrong as those are set b
On 15 April 2016 at 19:28, Brian Paul wrote:
> Having the top-level lib/ directory is definitely a convenience. But I'm
> not sure I know what you're asking.
>
Hehe silly me. Let me try again.
Why do we have three different versions across the different libGL.so
files - 1.2 (dri based) 1.5 (gall
On 15 April 2016 at 19:26, Ilia Mirkin wrote:
> I tested this out, and noticed that I still had to have
> --with-gallium-drivers=swrast, or else swrast_dri.so didn't get
> built/installed. With swrast,swr it seems to work (at least glxinfo
> and glxgears produce expected results).
>
Indeed. We nee
https://bugs.freedesktop.org/show_bug.cgi?id=94955
--- Comment #2 from Roland Scheidegger ---
(In reply to Brian Paul from comment #1)
> (In reply to David Lonie from comment #0)
> > ==32054== Conditional jump or move depends on uninitialised value(s)
> > ==32054==at 0x5409DEE: lp_build_blend
_mesa_libgcrypt_init() returns NULL, but its return type is void.
Cc: Mark Janes
---
src/util/mesa-sha1.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/src/util/mesa-sha1.c b/src/util/mesa-sha1.c
index ca6b89b..b6a192f 100644
--- a/src/util/mesa-sha1.c
+++ b/src/util/mesa
On Thu, Apr 14, 2016 at 3:34 AM, Bas Nieuwenhuizen
wrote:
> From: Marek Olšák
>
> v2: use the correct IB to update request (Bas Nieuwenhuizen)
> ---
> src/gallium/drivers/radeon/radeon_winsys.h | 18 +++
> src/gallium/winsys/amdgpu/drm/amdgpu_cs.c | 48
> +++---
On 2016-04-15 19:23, Grigori Goronzy wrote:
On 2016-04-15 18:38, Ilia Mirkin wrote:
+ } else {
+ union pipe_color_union color;
+ switch (util_format_get_blocksizebits(res->format)) {
+ case 128:
+ sf->format = PIPE_FORMAT_R32G
Signed-off-by: Ilia Mirkin
---
src/gallium/drivers/swr/.gitignore | 7 +++
1 file changed, 7 insertions(+)
create mode 100644 src/gallium/drivers/swr/.gitignore
diff --git a/src/gallium/drivers/swr/.gitignore
b/src/gallium/drivers/swr/.gitignore
new file mode 100644
index 000..c5b6416
On 04/15/2016 12:07 PM, Emil Velikov wrote:
On 15 April 2016 at 16:36, Chuck Atkins wrote:
Instead of cascading support for various different implementations of
GLX, all three options are now specified through the --enable-glx
option:
Bth having the single switch looks a lot cleaner imho. Won
I tested this out, and noticed that I still had to have
--with-gallium-drivers=swrast, or else swrast_dri.so didn't get
built/installed. With swrast,swr it seems to work (at least glxinfo
and glxgears produce expected results).
Might be nice if just the swr bit of flipped on everything that was
ne
From: Emil Velikov
Unused as of commit dddedbec0ed "{st,targets}/nine: use static/dynamic
pipe-loader"
Signed-off-by: Emil Velikov
---
.../target-helpers/inline_wrapper_sw_helper.h | 42 --
1 file changed, 42 deletions(-)
delete mode 100644
src/gallium/auxiliary/targ
On 15 April 2016 at 18:53, Tim Rowley wrote:
> ---
> configure.ac | 3 +++
> src/gallium/auxiliary/target-helpers/sw_helper.h | 15 +--
> src/gallium/drivers/swr/Automake.inc | 7 +++
> src/gallium/targets/dri/Makefile.am
According to the p_state.h file,
unsigned samples; /**< Number of samples in a no-attachment
framebuffer */
unsigned layers; /**< Number of layers in a no-attachment
framebuffer */
so since the fb has attachments here, I think those fields are unused.
Cc'ing Edward since he added the
Should it instead properly initialize fb->samples/layers?
On Fri, Apr 15, 2016 at 2:15 PM, Brian Paul wrote:
> To silence a valgrind uninitialized memory warning.
>
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=94955
> Cc: "11.1 11.2"
> ---
> src/gallium/auxiliary/util/u_blitter.c |
On Thu, Apr 14, 2016 at 8:29 PM, Nicolai Hähnle wrote:
> On 13.04.2016 20:34, Bas Nieuwenhuizen wrote:
>>
>> This series implements updating descriptors using the constant engine.
>> This should result in a 0%-3% improvement for CPU bound applications,
>> as we only have to upload the change descr
To silence a valgrind uninitialized memory warning.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=94955
Cc: "11.1 11.2"
---
src/gallium/auxiliary/util/u_blitter.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/gallium/auxiliary/util/u_blitter.c
b/src/gallium/au
On 15 April 2016 at 16:36, Chuck Atkins wrote:
> Instead of cascading support for various different implementations of
> GLX, all three options are now specified through the --enable-glx
> option:
>
Bth having the single switch looks a lot cleaner imho. Wondering if
one shouldn't use --with-glx as
---
configure.ac | 3 +++
src/gallium/auxiliary/target-helpers/sw_helper.h | 15 +--
src/gallium/drivers/swr/Automake.inc | 7 +++
src/gallium/targets/dri/Makefile.am | 1 +
src/gallium/targets/pipe-loader/Makefile.am
https://bugs.freedesktop.org/show_bug.cgi?id=94955
--- Comment #1 from Brian Paul ---
(In reply to David Lonie from comment #0)
> Created attachment 122975 [details]
> apitrace
>
> There are some uninitialized variables in current master that are causing
> some of the VTK unit tests to segfault
Hi,
apps that cause a lot of synchronization benefit from small IB
sizes. The current IB size is a bit on the large side for this class
of apps. On the other hand, if there isn't much synchronization going
on, increasing the IB size can slightly improve performance, too.
Here's a quick hack that
Small IBs help to reduce stalls for workloads that require a lot of
synchronization. On the other hand, if there is no notable
synchronization, we can use a large IB size to slightly improve
performance in some cases.
This introduces tuning of the IB size based on feedback on the average
buffer wa
For all patches that don't contain my Rb except 17:
Reviewed-by: Marek Olšák
SURFACE_SYNC & ACQUIRE_MEM only wait for VS and PS if any of the
BASE_ENA flags are set (according to our closed driver code). They
don't wait for CS. Flushing L2 doesn't wait for anything.
Marek
On Wed, Apr 13, 2016
On 15 April 2016 at 00:30, Tim Rowley wrote:
> --- a/src/gallium/drivers/swr/Makefile.am
> +++ b/src/gallium/drivers/swr/Makefile.am
> @@ -22,7 +22,7 @@
> include Makefile.sources
> include $(top_srcdir)/src/gallium/Automake.inc
>
> -AM_CXXFLAGS = $(GALLIUM_DRIVER_CFLAGS)
> +AM_CXXFLAGS = $(GAL
https://bugs.freedesktop.org/show_bug.cgi?id=94955
Bug ID: 94955
Summary: Uninitialized variables leads to random segfaults
(valgrind log, apitrace attached)
Product: Mesa
Version: git
Hardware: All
OS: All
On 14 April 2016 at 20:40, Rob Herring wrote:
> A couple more Android build fixes after rebasing to the current tip.
>
> Android master builds are still a bit broken because makefiles get
> processed by kati in a different order. To fix, we need to go thru and
> eliminate all the variables set by
On 14 April 2016 at 20:40, Rob Herring wrote:
> Commit bfd17c76c126 ("i965: Port INTEL_PRECISE_TRIG=1 to NIR.") added a
> generated file brw_nir_trig_workarounds.c which broke the Android build.
> Add the necessary makefiles to the Android build.
>
> Cc: Kenneth Graunke
> Cc: Emil Velikov
> Sign
https://bugs.freedesktop.org/show_bug.cgi?id=94086
Chuck Atkins changed:
What|Removed |Added
Attachment #122938|0 |1
is obsolete|
On 2016-04-15 18:38, Ilia Mirkin wrote:
+ } else {
+ union pipe_color_union color;
+ switch (util_format_get_blocksizebits(res->format)) {
+ case 128:
+ sf->format = PIPE_FORMAT_R32G32B32A32_UINT;
Just as an FYI... this is sa
On 14 April 2016 at 20:40, Rob Herring wrote:
> Commit 4db8f15a2576 ("glsl: move the android build scripts a level up")
> dropped a generated include path for glcpp. Add it back adjusting for the
> new location.
>
> Cc: Emil Velikov
> Signed-off-by: Rob Herring
> ---
> src/compiler/Android.glsl
>
> > Put x in front of everything:
> >
> Which reminds me - what are the advantages of it ? In the gallium
> drivers (where this is derived from) and I've not seen any issues.
> Mostly curious, I'm fine with or without the x.
>
It prevents empty string problems. If the variable is undefined or
e
Hi,
It might also be worth testing the impact of IOMMU L1 on GTT throughput.
Set IOMMU_L2INDX:L2_DEBUG_3 bit 31 (at any time) to disable the L1.
On 2016-04-14 06:28, Christian König wrote:
Yeah, thinking about this since I've seen Michels response this
morning.
The only major thing which is
On Fri, Apr 15, 2016 at 12:33 PM, Jakob Sinclair
wrote:
> This patch adds the needed function for ARB_clear_texture.
> The function itself is mostly based on the nouveau implementation.
>
> Signed-off-by: Jakob Sinclair
> ---
> src/gallium/drivers/radeon/r600_texture.c | 72
> ++
On Fri, Apr 15, 2016 at 10:02 AM, Emil Velikov
wrote:
> On 14 April 2016 at 21:51, Kenneth Graunke wrote:
> > On Thursday, April 14, 2016 1:06:25 PM PDT Jason Ekstrand wrote:
> >> This adds a --with-vulkan-drivers option with one driver, "intel". In
> the
> >> future, we may add more drivers to
On 14 April 2016 at 21:51, Kenneth Graunke wrote:
> On Thursday, April 14, 2016 1:06:25 PM PDT Jason Ekstrand wrote:
>> This adds a --with-vulkan-drivers option with one driver, "intel". In the
>> future, we may add more drivers to this list.
>> ---
>> configure.ac | 66 +
On 04/15/2016 10:18 AM, Chuck Atkins wrote:
The problem this is trying to solve is that they both get installed and
create an ambiguous situation for which one get's used:
libGL.so -> libGL.so.1.5.0
libGL.so.1 -> libGL.so.1.6.0
libGL.so.1.5.0
libGL.so.1.6.0
I could adjust it so that you can bui
This series of patches implements ARB_clear_texture for r600 and radeonsi.
I only tested this with the radeonsi driver and just assumed it would work
on the r600 driver. If someone could test this with the r600 driver it would
be wonderful. This implementation was mostly based on the nouveau
implem
On 04/15/2016 10:22 AM, Ilia Mirkin wrote:
On Fri, Apr 15, 2016 at 12:18 PM, Chuck Atkins wrote:
The problem this is trying to solve is that they both get installed and
create an ambiguous situation for which one get's used:
libGL.so -> libGL.so.1.5.0
libGL.so.1 -> libGL.so.1.6.0
libGL.so.1.5.
On 2016-04-15 18:38, Ilia Mirkin wrote:
Just as an FYI... this is safe on nouveau because I control all the
internals and know that this is safe to do. Please verify that it's
similarly safe to change the surface format after creation on radeon -
it might not be. (Esp for compressed textures...)
On 04/15/2016 10:30 AM, Rob Clark wrote:
On Fri, Apr 15, 2016 at 11:06 AM, Brian Paul wrote:
On 04/15/2016 08:49 AM, Rob Clark wrote:
From: Rob Clark
We'll want to re-use this for NIR.
Signed-off-by: Rob Clark
Reviewed-by: Marek Olšák
---
src/mesa/Makefile.sources |
On Fri, Apr 15, 2016 at 12:33 PM, Jakob Sinclair
wrote:
> This patch adds the needed function for ARB_clear_texture.
> The function itself is mostly based on the nouveau implementation.
>
> Signed-off-by: Jakob Sinclair
> ---
> src/gallium/drivers/radeon/r600_texture.c | 72
> ++
Signed-off-by: Jakob Sinclair
---
src/gallium/drivers/r600/r600_pipe.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/gallium/drivers/r600/r600_pipe.c
b/src/gallium/drivers/r600/r600_pipe.c
index c594f5c..7d1d6b2 100644
--- a/src/gallium/drivers/r600/r600_pipe.c
+++ b/sr
1 - 100 of 155 matches
Mail list logo
