On 02/11/2015 12:28 AM, Emil Velikov wrote:
> I'm guessing that this was meant for the piglit ML - Cc-ing it :)
>
Oh, sorry for the mistake and thank you Emil!
cheers,
Eduardo
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freed
Is there any indication on when is this "temporary" hack going to be removed?
This kind of linking is not legal in many toolchains (eg on darwin), and I
imagine behavior is not well defined in places where this hack actually works.
--Jeremy
commit 7414552b1826ece48a622c14b48cad3a37b68025
Autho
Since you always need to have a fallback anyway in case you got memory
the GPU can't handle (mapped file etc...) you can just call the IOCTL,
check the return value and if it didn't worked go the fallback path.
Or do you need to know if it's available or not to make the extension
available or
https://bugs.freedesktop.org/show_bug.cgi?id=89068
--- Comment #5 from Iago Toral ---
(In reply to Iago Toral from comment #4)
> (In reply to Brad King from comment #0)
> (...)
> > After the change, _mesa_format_convert is called but none of the coe paths
> > invoking _mesa_pack_ubyte_rgba_row is
On Wed, Feb 11, 2015 at 9:48 AM, Christian König
wrote:
> Since you always need to have a fallback anyway in case you got memory the
> GPU can't handle (mapped file etc...) you can just call the IOCTL, check the
> return value and if it didn't worked go the fallback path.
>
> Or do you need to kno
libOSMesa is a library, not a module
Signed-off-by: Jeremy Huddleston Sequoia
---
src/mesa/drivers/osmesa/Makefile.am | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/mesa/drivers/osmesa/Makefile.am
b/src/mesa/drivers/osmesa/Makefile.am
index 589b5ee..8d69915 100644
--- a/src/mesa/drivers
The intel driver code, and apparently all other Mesa drivers, call
_mesa_initialize_context early in the CreateContext hook. That
function will end up calling _mesa_init_texture which will do:
ctx->Texture.CubeMapSeamless = _mesa_is_gles3(ctx);
But this won't work at this point, since _mesa_is_gl
On 11 February 2015 at 07:58, Jeremy Huddleston Sequoia
wrote:
> Is there any indication on when is this "temporary" hack going to be removed?
> This kind of linking is not legal in many toolchains (eg on darwin), and I
> imagine behavior is not well defined in places where this hack actually w
On 11 February 2015 at 10:32, Jeremy Huddleston Sequoia
wrote:
> libOSMesa is a library, not a module
>
Fwiw I'm not 100% sure that's the case. But considering it's been like
that* for a long time we should be safe.
Just a couple small requests - can you clarify what you mean with "Fix
install nam
On Tuesday, February 10, 2015 05:22:45 PM Ben Widawsky wrote:
> Since we can be in this code with SIMD4x2, the execsize will be 4, and so the
> register width must be <= 4. If you use a vec8, the width is 8, and we'll
> assert
> fail.
NAK with this rationale.
brw_fs*.cpp is _only_ for SIMD8 (or
On Tuesday, February 10, 2015 08:08:38 PM Matt Turner wrote:
> Dead since
>
>commit 284ce20901b0c2cfab1d952cc129b8f3cd068f12
>Author: Eric Anholt
>Date: Fri Aug 20 10:52:14 2010 -0700
>
>Remove remnants of the old glsl compiler.
> ---
> src/mesa/program/programopt.c | 91
On Friday, February 06, 2015 09:16:44 PM Eric Anholt wrote:
> NIR instruction count results on i965:
> total instructions in shared programs: 1261954 -> 1261937 (-0.00%)
> instructions in affected programs: 455 -> 438 (-3.74%)
>
> One in yofrankie, two in tropics. Apparently i965 had also opt
On Tuesday, February 10, 2015 01:52:41 PM Juha-Pekka Heikkila wrote:
> Signed-off-by: Juha-Pekka Heikkila
> ---
> src/glsl/nir/nir_print.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/src/glsl/nir/nir_print.c b/src/glsl/nir/nir_print.c
> index 9c07950..c250850 100644
> --- a/src/g
https://bugs.freedesktop.org/show_bug.cgi?id=89068
--- Comment #6 from Brad King ---
Thanks for taking a look!
I've just run a debug session with commit 1e02f2ba checked out.
> what GPU are you running on?
I'm building software-only:
./autogen.sh --prefix="..." \
--disable-dri --disable-e
From: Marek Olšák
I forgot to do this, though "true" should have no effect on correctness.
---
src/gallium/drivers/radeon/r600_buffer_common.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/src/gallium/drivers/radeon/r600_buffer_common.c
b/src/gallium/drivers/radeon/r600_buffer_common.c
in
From: Marek Olšák
Cc: 10.4
---
src/gallium/drivers/radeonsi/si_state_shaders.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/src/gallium/drivers/radeonsi/si_state_shaders.c
b/src/gallium/drivers/radeonsi/si_state_shaders.c
index 27ccc8e..dea99ea 100644
--- a/src/gal
From: Marek Olšák
This is the same as the Mesa core setting.
This avoids a serious r600g bug.
Bugzilla:_https://bugs.freedesktop.org/show_bug.cgi?id=86720
Cc: 10.5 10.4 10.3
---
src/gallium/auxiliary/gallivm/lp_bld_limits.h| 2 ++
src/gallium/auxiliary/tgsi/tgsi_exec.h | 2 ++
s
From: Marek Olšák
---
src/gallium/drivers/radeon/r600_query.c | 22 +-
1 file changed, 13 insertions(+), 9 deletions(-)
diff --git a/src/gallium/drivers/radeon/r600_query.c
b/src/gallium/drivers/radeon/r600_query.c
index 4571b3c..8d80612 100644
--- a/src/gallium/drivers/rad
From: Marek Olšák
The query result is always constant.
---
src/gallium/drivers/radeon/r600_query.c | 27 +--
1 file changed, 13 insertions(+), 14 deletions(-)
diff --git a/src/gallium/drivers/radeon/r600_query.c
b/src/gallium/drivers/radeon/r600_query.c
index 590db13..4
From: Marek Olšák
Cc: 10.5 10.4 10.3
---
src/mesa/main/bufferobj.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/mesa/main/bufferobj.c b/src/mesa/main/bufferobj.c
index 0c1ce98..0c23b42 100644
--- a/src/mesa/main/bufferobj.c
+++ b/src/mesa/main/bufferobj.c
@@ -1226,7 +
There is no error path available thus instead of giving
realloc possibility to fail use new which will never
return null pointer and throws bad_alloc on failure.
Signed-off-by: Juha-Pekka Heikkila
---
src/mesa/drivers/dri/i965/brw_ir_allocator.h | 19 +++
1 file changed, 15 inser
There is no error path available thus instead of giving
realloc possibility to fail use new which will never
return null pointer and throws bad_alloc on failure.
Signed-off-by: Juha-Pekka Heikkila
---
src/mesa/drivers/dri/i965/brw_ir_allocator.h | 16
1 file changed, 12 insertio
On 02/11/2015 07:24 AM, Marek Olšák wrote:
From: Marek Olšák
Cc: 10.5 10.4 10.3
---
src/mesa/main/bufferobj.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/mesa/main/bufferobj.c b/src/mesa/main/bufferobj.c
index 0c1ce98..0c23b42 100644
--- a/src/mesa/main/bufferobj
On 02/11/2015 07:23 AM, Marek Olšák wrote:
From: Marek Olšák
This is the same as the Mesa core setting.
This avoids a serious r600g bug.
Bugzilla:_https://bugs.freedesktop.org/show_bug.cgi?id=86720
Cc: 10.5 10.4 10.3
---
src/gallium/auxiliary/gallivm/lp_bld_limits.h| 2 ++
src/gallium
I don't think this is a good idea. This pollutes the gallium interface
(albeit in some rather minor way, but still) to just cover up a driver
bug. It does not do anything to actually fix the root cause of the bug
(presumably it would still just lock up if the loop would actually have
256 iterations
This is done the same way for glsl et al. already
Signed-off-by: Tobias Klausmann
---
src/gallium/include/pipe/p_compiler.h | 23 +++
1 file changed, 23 insertions(+)
diff --git a/src/gallium/include/pipe/p_compiler.h
b/src/gallium/include/pipe/p_compiler.h
index fb018bf..6
Signed-off-by: Tobias Klausmann
---
src/gallium/state_trackers/nine/nine_pipe.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/gallium/state_trackers/nine/nine_pipe.h
b/src/gallium/state_trackers/nine/nine_pipe.h
index 17844d5..b8e728e 100644
--- a/src/gallium/state_trac
It's already defined in src/util/macros.h which you can include via
#include "util/macros.h" -- I suspect some key gallium file should
include that...
On Wed, Feb 11, 2015 at 10:47 AM, Tobias Klausmann
wrote:
> This is done the same way for glsl et al. already
>
> Signed-off-by: Tobias Klausmann
Juha-Pekka Heikkila writes:
> There is no error path available thus instead of giving
> realloc possibility to fail use new which will never
> return null pointer and throws bad_alloc on failure.
>
> Signed-off-by: Juha-Pekka Heikkila
> ---
> src/mesa/drivers/dri/i965/brw_ir_allocator.h | 16 ++
On Wed, Feb 11, 2015 at 6:37 AM, Juha-Pekka Heikkila
wrote:
> There is no error path available thus instead of giving
> realloc possibility to fail use new which will never
> return null pointer and throws bad_alloc on failure.
The problem was that we weren't checking if realloc failed.
Why is t
Matt Turner writes:
> On Wed, Feb 11, 2015 at 6:37 AM, Juha-Pekka Heikkila
> wrote:
>> There is no error path available thus instead of giving
>> realloc possibility to fail use new which will never
>> return null pointer and throws bad_alloc on failure.
>
> The problem was that we weren't check
On Tue, Feb 10, 2015 at 11:00 PM, Samuel Iglesias Gonsálvez
wrote:
> On Tuesday 10 February 2015 11:32:32 Matt Turner wrote:
>> On Tue, Feb 10, 2015 at 10:52 AM, Matt Turner wrote:
>> >> + /* Round floating point values to nearest integer to avoid "off by
>> >> one texel" +* kind of errors
Reviewed-by: Matt Turner
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
On Wed, Feb 11, 2015 at 9:16 AM, Francisco Jerez wrote:
> Matt Turner writes:
>
>> On Wed, Feb 11, 2015 at 6:37 AM, Juha-Pekka Heikkila
>> wrote:
>>> There is no error path available thus instead of giving
>>> realloc possibility to fail use new which will never
>>> return null pointer and throw
On 11.02.2015 19:02, Matt Turner wrote:
> On Wed, Feb 11, 2015 at 6:37 AM, Juha-Pekka Heikkila
> wrote:
>> There is no error path available thus instead of giving
>> realloc possibility to fail use new which will never
>> return null pointer and throws bad_alloc on failure.
>
> The problem was th
I completely agree with you. Turning off the R600 optimizing Shader
Backend would also work, but the performance drop would be unpleasant.
Marek
On Wed, Feb 11, 2015 at 4:11 PM, Roland Scheidegger wrote:
> I don't think this is a good idea. This pollutes the gallium interface
> (albeit in some r
Matt Turner writes:
> On Wed, Feb 11, 2015 at 9:16 AM, Francisco Jerez
> wrote:
>> Matt Turner writes:
>>
>>> On Wed, Feb 11, 2015 at 6:37 AM, Juha-Pekka Heikkila
>>> wrote:
There is no error path available thus instead of giving
realloc possibility to fail use new which will never
On Wed, Feb 11, 2015 at 12:30 PM, Francisco Jerez
wrote:
> Matt Turner writes:
>
> > On Wed, Feb 11, 2015 at 9:16 AM, Francisco Jerez
> wrote:
> >> Matt Turner writes:
> >>
> >>> On Wed, Feb 11, 2015 at 6:37 AM, Juha-Pekka Heikkila
> >>> wrote:
> There is no error path available thus ins
On Wed, Feb 11, 2015 at 9:35 AM, Jason Ekstrand wrote:
> On Wed, Feb 11, 2015 at 12:30 PM, Francisco Jerez
> wrote:
>>
>> Matt Turner writes:
>>
>> > On Wed, Feb 11, 2015 at 9:16 AM, Francisco Jerez
>> > wrote:
>> >> Matt Turner writes:
>> >>
>> >>> On Wed, Feb 11, 2015 at 6:37 AM, Juha-Pekka
And unfortunately other shaders do the same thing but with >=/<= which
we can't apply this optimization to because of NaNs.
instructions in affected programs: 23309 -> 22938 (-1.59%)
---
src/glsl/nir/nir_opt_algebraic.py | 2 ++
1 file changed, 2 insertions(+)
diff --git a/src/glsl/nir/nir_o
> On Feb 11, 2015, at 05:02, Emil Velikov wrote:
>
> On 11 February 2015 at 10:32, Jeremy Huddleston Sequoia
> wrote:
>> libOSMesa is a library, not a module
>>
> Fwiw I'm not 100% sure that's the case. But considering it's been like
> that* for a long time we should be safe.
> Just a couple s
Reviewed-by: Matt Turner
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
On Wed, Feb 11, 2015 at 05:08:33AM -0800, Kenneth Graunke wrote:
> On Tuesday, February 10, 2015 05:22:45 PM Ben Widawsky wrote:
> > Since we can be in this code with SIMD4x2, the execsize will be 4, and so
> > the
> > register width must be <= 4. If you use a vec8, the width is 8, and we'll
> >
On Wednesday, February 11, 2015 04:56:56 PM Juha-Pekka Heikkila wrote:
> There is no error path available thus instead of giving
> realloc possibility to fail use new which will never
> return null pointer and throws bad_alloc on failure.
>
> Signed-off-by: Juha-Pekka Heikkila
> ---
> src/mesa/d
On Wednesday, February 11, 2015 09:58:28 AM Matt Turner wrote:
> And unfortunately other shaders do the same thing but with >=/<= which
> we can't apply this optimization to because of NaNs.
>
> instructions in affected programs: 23309 -> 22938 (-1.59%)
> ---
> src/glsl/nir/nir_opt_algebraic.
On Monday, February 09, 2015 02:23:25 PM Jason Ekstrand wrote:
> ---
> src/glsl/nir/nir_lower_phis_to_scalar.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/src/glsl/nir/nir_lower_phis_to_scalar.c
> b/src/glsl/nir/nir_lower_phis_to_scalar.c
> index 3bb5cc7..7cd93
https://bugs.freedesktop.org/show_bug.cgi?id=89088
Bug ID: 89088
Summary: Mesa fails to build if indent does not support
requested arguments (eg: -nut)
Product: Mesa
Version: 10.4
Hardware: Other
OS: All
This patch is
Reviewed-by: Ian Romanick
On 02/10/2015 03:58 AM, Ilia Mirkin wrote:
> This causes a lot of warnings about unchecked type in
> switch statements - fix them later.
>
> Signed-off-by: Dave Airlie
> Reviewed-by: Matt Turner
> ---
> src/glsl/glsl_types.h | 9 +
> 1 file cha
On Wednesday, February 11, 2015 10:35:04 AM Ben Widawsky wrote:
> On Wed, Feb 11, 2015 at 05:08:33AM -0800, Kenneth Graunke wrote:
> > On Tuesday, February 10, 2015 05:22:45 PM Ben Widawsky wrote:
> > > Since we can be in this code with SIMD4x2, the execsize will be 4, and so
> > > the
> > > regis
Kenneth Graunke writes:
> On Tuesday, February 10, 2015 08:08:38 PM Matt Turner wrote:
>> Dead since
>>
>>commit 284ce20901b0c2cfab1d952cc129b8f3cd068f12
>>Author: Eric Anholt
>>Date: Fri Aug 20 10:52:14 2010 -0700
>>
>>Remove remnants of the old glsl compiler.
>> ---
>>
Reviewed-by: Ian Romanick
On 02/06/2015 12:36 AM, Kenneth Graunke wrote:
> I used this a while back when debugging GPU hangs, and it seems like it
> could be useful, so I figured I'd add it so people can use it in the
> debugger.
>
> Signed-off-by: Kenneth Graunke
> ---
> src/mesa/drivers/dri/
Connor Abbott writes:
> On Tue, Feb 10, 2015 at 1:32 PM, Eric Anholt wrote:
>> Connor Abbott writes:
>>
>>> On Sat, Feb 7, 2015 at 12:16 AM, Eric Anholt wrote:
NIR instruction count results on i965:
total instructions in shared programs: 1261954 -> 1261937 (-0.00%)
instructions
https://bugs.freedesktop.org/show_bug.cgi?id=0
--- Comment #2 from Ian Romanick ---
It's invalid because the code referenced in the bug report was removed by
commit 7ef4a07 in July 2006. I think it's time for any upgrade. :)
See also bug #7353.
--
You are receiving this mail because:
You
On Wed, Feb 11, 2015 at 2:36 PM, Eric Anholt wrote:
> Connor Abbott writes:
>
>> On Tue, Feb 10, 2015 at 1:32 PM, Eric Anholt wrote:
>>> Connor Abbott writes:
>>>
On Sat, Feb 7, 2015 at 12:16 AM, Eric Anholt wrote:
> NIR instruction count results on i965:
> total instructions in s
Since condition_list is an ordered list, we can just use enumerate()
when walking through it to get (index, value) pairs, rather than storing
a second dictionary mapping items to their indices. When looking for an
existing entry, use list.index() to get the index of that item.
---
src/glsl/nir/ni
Matt Turner writes:
>[...]
> Indeed. And another thing to consider is that we've discussed
> compiling with -fno-exceptions.
>
Heh, the benefit you get from doing that is virtually zero. And in
cases like this where failure would have to be handled many levels up in
the stack and require redesig
Connor Abbott writes:
> On Wed, Feb 11, 2015 at 2:36 PM, Eric Anholt wrote:
>> Connor Abbott writes:
>>
>>> On Tue, Feb 10, 2015 at 1:32 PM, Eric Anholt wrote:
Connor Abbott writes:
> On Sat, Feb 7, 2015 at 12:16 AM, Eric Anholt wrote:
>> NIR instruction count results on i9
From: Marek Olšák
It's not possible to query the current buffer binding, because the extension
doesn't define GL_..._BUFFER__BINDING_AMD.
Drivers should check the target parameter of Drivers.BufferData. If it's
equal to GL_EXTERNAL_VIRTUAL_MEMORY_BUFFER_AMD, the memory should be pinned.
That's a
From: Marek Olšák
OpenGL requires this.
---
src/gallium/winsys/radeon/drm/radeon_drm_bo.c | 5 +
src/gallium/winsys/radeon/drm/radeon_drm_bo.h | 1 +
src/gallium/winsys/radeon/drm/radeon_winsys.h | 4 ++--
3 files changed, 8 insertions(+), 2 deletions(-)
diff --git a/src/gallium/winsys/rade
From: Marek Olšák
---
src/gallium/docs/source/screen.rst | 5 +
src/gallium/drivers/i915/i915_screen.c | 1 +
src/gallium/drivers/ilo/ilo_screen.c | 1 +
src/gallium/drivers/llvmpipe/lp_screen.c | 1 +
src/gallium/drivers/nouveau/nv30/nv30_screen.c |
From: Marek Olšák
This is not required, but being user-friendly doesn't hurt.
---
src/gallium/winsys/radeon/drm/radeon_drm_bo.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/gallium/winsys/radeon/drm/radeon_drm_bo.c
b/src/gallium/winsys/radeon/drm/radeon_drm_bo.c
index
From: Marek Olšák
There seems to be no other way to check for support.
The DRM version wasn't bumped.
---
src/gallium/winsys/radeon/drm/radeon_drm_bo.c | 18 --
src/gallium/winsys/radeon/drm/radeon_drm_cs.h | 1 -
src/gallium/winsys/radeon/drm/radeon_drm_winsys.c | 15 ++
From: Marek Olšák
---
src/gallium/drivers/r600/r600_pipe.c| 3 ++
src/gallium/drivers/radeon/r600_buffer_common.c | 47 ++---
src/gallium/drivers/radeon/r600_pipe_common.c | 1 +
src/gallium/drivers/radeon/r600_pipe_common.h | 4 +++
src/gallium/drivers/rad
On Wed, Feb 11, 2015 at 3:17 PM, Eric Anholt wrote:
> Connor Abbott writes:
>
>> On Wed, Feb 11, 2015 at 2:36 PM, Eric Anholt wrote:
>>> Connor Abbott writes:
>>>
On Tue, Feb 10, 2015 at 1:32 PM, Eric Anholt wrote:
> Connor Abbott writes:
>
>> On Sat, Feb 7, 2015 at 12:16 AM,
https://bugs.freedesktop.org/show_bug.cgi?id=89088
--- Comment #1 from Matt Turner ---
A commit was made recently to require GNU indent:
commit efef6c828092702b1f928f98d15fb90b4544a85c
Author: Samuel Iglesias Gonsalvez
Date: Tue Jan 13 11:02:27 2015 +0100
configure: add check for GNU ind
Signed-off-by: Jeremy Huddleston Sequoia
---
include/GL/glext.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/include/GL/glext.h b/include/GL/glext.h
index 256ad35..0328cf6 100644
--- a/include/GL/glext.h
+++ b/include/GL/glext.h
@@ -4470,6 +4470,7 @@ GLAPI void APIENTRY glVertexBlendARB (
On Wed, Feb 11, 2015 at 12:36 PM, Jeremy Huddleston Sequoia
wrote:
>
> Signed-off-by: Jeremy Huddleston Sequoia
The file comes from Khronos. We can't update it.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailm
We were filling out almost all fields of almost all instructions, but
leaving out a couple of them. This simplifies the source code, cuts 700
bytes from the compiled binary, and prevents developer surprise when one
field of your otherwise-containing-defaults struct is actually
uninitialized.
---
On 11.02.2015 16:50, Ilia Mirkin wrote:
It's already defined in src/util/macros.h which you can include via
#include "util/macros.h" -- I suspect some key gallium file should
include that...
Mh, i was under the expression these should be duped, as we already have
STATIC_ASSERT and likely/unlike
https://bugs.freedesktop.org/show_bug.cgi?id=89050
Ian Romanick changed:
What|Removed |Added
Status|NEW |NEEDINFO
Assignee|mesa-dev@list
https://bugs.freedesktop.org/show_bug.cgi?id=79629
--- Comment #18 from Chris Wilson ---
*** Bug 89050 has been marked as a duplicate of this bug. ***
--
You are receiving this mail because:
You are the assignee for the bug.
___
mesa-dev mailing list
https://bugs.freedesktop.org/show_bug.cgi?id=89050
Chris Wilson changed:
What|Removed |Added
Status|NEEDINFO|RESOLVED
Resolution|---
https://bugs.freedesktop.org/show_bug.cgi?id=89088
--- Comment #2 from Jeremy Huddleston ---
No, I was encountering this on the MacPorts Snow Leopard buildbot after
updating mesa from 8.0.5 to 10.4.4. We should probably cherry-pick that into
10.5 and 10.4.
--
You are receiving this mail becaus
https://bugs.freedesktop.org/show_bug.cgi?id=88852
Ian Romanick changed:
What|Removed |Added
Status|NEW |NEEDINFO
--- Comment #2 from Ian Romanick
https://bugs.freedesktop.org/show_bug.cgi?id=88852
Jason Ekstrand changed:
What|Removed |Added
Status|NEEDINFO|RESOLVED
Resolution|---
I didn't look through it close enough to call it a review, but I like it.
Especially getting rid of src/def_init.
Acked-by: Jason Ekstrand
On Wed, Feb 11, 2015 at 4:32 PM, Eric Anholt wrote:
> We were filling out almost all fields of almost all instructions, but
> leaving out a couple of them.
https://bugs.freedesktop.org/show_bug.cgi?id=88535
Ian Romanick changed:
What|Removed |Added
Status|NEW |NEEDINFO
--- Comment #3 from Ian Romanick
This is safer and matches the conditional_mod propagation pass.
Cc:
---
.../dri/i965/brw_fs_saturate_propagation.cpp | 8 ++---
.../dri/i965/test_fs_saturate_propagation.cpp | 40 ++
2 files changed, 44 insertions(+), 4 deletions(-)
diff --git a/src/mesa/drivers/
total instructions in shared programs: 5932832 -> 5932736 (-0.00%)
instructions in affected programs: 8184 -> 8088 (-1.17%)
helped:52
HURT: 14
GAINED:1
---
src/mesa/drivers/dri/i965/brw_fs_visitor.
The saturate propagation pass recognizes that the second instruction
below does not interfere with an attempt to propagate the saturate
modifier from instruction 3 to 1.
1: add(8) dst0 src0 src1
2: mov.sat(8) dst1 dst0
3: mov.sat(8) dst2 dst0
Unfortunately, we did not consider th
mul x, -y is equivalent to mul -x, y; and mul x, y is the negation of
mul x, -y.
total instructions in shared programs: 5937689 -> 5929512 (-0.14%)
instructions in affected programs: 871152 -> 862975 (-0.94%)
helped:4228
HURT: 17
We propagate negations to the right-most leaves of the multiplication
expression trees:
- mul(neg(x), neg(y)) -> mul(x, y)
- mul(neg(x), y) -> neg(mul(x, y))
- mul(x, neg(y)) -> neg(mul(x, y))
total instructions in shared programs: 5943123 -> 5937229 (-0.10%)
instructions in affected programs:
Cc:
---
src/mesa/drivers/dri/i965/Makefile.am | 7 +
.../dri/i965/test_fs_saturate_propagation.cpp | 355 +
2 files changed, 362 insertions(+)
create mode 100644 src/mesa/drivers/dri/i965/test_fs_saturate_propagation.cpp
diff --git a/src/mesa/drivers/dri/
https://bugs.freedesktop.org/show_bug.cgi?id=86944
Ian Romanick changed:
What|Removed |Added
Status|NEW |NEEDINFO
--- Comment #10 from Ian Romanic
https://bugs.freedesktop.org/show_bug.cgi?id=79706
Bug 79706 depends on bug 82471, which changed state.
Bug 82471 Summary: [swrast] piglit fp-condition_codes-01 regression
https://bugs.freedesktop.org/show_bug.cgi?id=82471
What|Removed |Added
---
https://bugs.freedesktop.org/show_bug.cgi?id=82477
--- Comment #3 from Ian Romanick ---
*** Bug 82471 has been marked as a duplicate of this bug. ***
--
You are receiving this mail because:
You are the assignee for the bug.
___
mesa-dev mailing list
m
https://bugs.freedesktop.org/show_bug.cgi?id=82471
Ian Romanick changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://bugs.freedesktop.org/show_bug.cgi?id=89088
Matt Turner changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|mesa-dev@lists
Reviewed-by: Connor Abbott
On Mon, Feb 9, 2015 at 11:24 PM, Jason Ekstrand wrote:
> Being able to find the least common anscestor in the dominance tree is a
> useful thing that we may want to do in other passes. In particular, we
> need it for GCM.
>
> v2: Handle NULL inputs by returning the ot
On Mon, Feb 9, 2015 at 6:00 PM, Kenneth Graunke wrote:
> With that fixed, and the shader-db numbers confirmed, patches 9-10 are:
> Reviewed-by: Kenneth Graunke
To close the loop, the shader-db results are unchanged after the fix.
___
mesa-dev mailing l
On 02/11/2015 02:54 PM, Matt Turner wrote:
> We propagate negations to the right-most leaves of the multiplication
> expression trees:
>
> - mul(neg(x), neg(y)) -> mul(x, y)
> - mul(neg(x), y) -> neg(mul(x, y))
> - mul(x, neg(y)) -> neg(mul(x, y))
>
> total instructions in shared programs: 594
On 02/11/2015 02:54 PM, Matt Turner wrote:
> total instructions in shared programs: 5932832 -> 5932736 (-0.00%)
> instructions in affected programs: 8184 -> 8088 (-1.17%)
> helped:52
> HURT: 14
> GAINED:
https://bugs.freedesktop.org/show_bug.cgi?id=63717
Matt Turner changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
I was wondering when you'd get around to implementing this. :)
This patch is
Reviewed-by: Ian Romanick
On 02/11/2015 12:18 PM, Marek Olšák wrote:
> From: Marek Olšák
>
> It's not possible to query the current buffer binding, because the extension
> doesn't define GL_..._BUFFER__BINDING_AMD.
>
On Wed, Feb 11, 2015 at 3:51 PM, Ian Romanick wrote:
> On 02/11/2015 02:54 PM, Matt Turner wrote:
>> We propagate negations to the right-most leaves of the multiplication
>> expression trees:
>>
>> - mul(neg(x), neg(y)) -> mul(x, y)
>> - mul(neg(x), y) -> neg(mul(x, y))
>> - mul(x, neg(y)) -> n
On Wed, Feb 11, 2015 at 3:57 PM, Ian Romanick wrote:
> On 02/11/2015 02:54 PM, Matt Turner wrote:
>> total instructions in shared programs: 5932832 -> 5932736 (-0.00%)
>> instructions in affected programs: 8184 -> 8088 (-1.17%)
>> helped:52
>> HURT:
On 02/11/2015 12:15 PM, Francisco Jerez wrote:
> Matt Turner writes:
>> [...]
>> Indeed. And another thing to consider is that we've discussed
>> compiling with -fno-exceptions.
>>
>
> Heh, the benefit you get from doing that is virtually zero. And in
> cases like this where failure would have t
On 02/11/2015 04:05 PM, Matt Turner wrote:
> On Wed, Feb 11, 2015 at 3:51 PM, Ian Romanick wrote:
>> On 02/11/2015 02:54 PM, Matt Turner wrote:
>>> We propagate negations to the right-most leaves of the multiplication
>>> expression trees:
>>>
>>> - mul(neg(x), neg(y)) -> mul(x, y)
>>> - mul(neg
https://bugs.freedesktop.org/show_bug.cgi?id=5
Carl Worth changed:
What|Removed |Added
Assignee|mesa-dev@lists.freedesktop. |cwo...@cworth.org
|org
Quiets compiler warning since e7f2f2dea5acdbd1a12ed88914e64a38a97432f0.
---
src/mesa/drivers/dri/r200/r200_ioctl.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/mesa/drivers/dri/r200/r200_ioctl.c
b/src/mesa/drivers/dri/r200/r200_ioctl.c
index 515be92..d665c8b 100644
--- a/src/mesa/driver
1 - 100 of 158 matches
Mail list logo
