From: Ian Romanick ian.d.roman...@intel.com
Both the AMD and Intel APIs provide a dataSize parameter, and this
function would merrily ignore it. Neither API specifies what to do when
the buffer isn't big enough. I take the easy route of writing all the
complete bits of data that will fit. With
From: Ian Romanick ian.d.roman...@intel.com
Unused since b18fd23.
brw_fs.cpp:2878:44: warning: unused parameter 'dispatch_width'
[-Wunused-parameter]
clear_deps_for_inst_src(fs_inst *inst, int dispatch_width, bool *deps,
^
Signed-off-by: Ian
From: Ian Romanick ian.d.roman...@intel.com
brw_fs_visitor.cpp:2162:56: warning: unused parameter 'offset_components'
[-Wunused-parameter]
fs_reg offset_value, unsigned offset_components,
^
Signed-off-by: Ian
From: Ian Romanick ian.d.roman...@intel.com
All dd functions take a gl_context as the first parameter. Instead of
removing it, just silence the warning.
brw_performance_monitor.c: In function 'brw_new_perf_monitor':
brw_performance_monitor.c:1354:41: warning: unused parameter 'ctx'
From: Ian Romanick ian.d.roman...@intel.com
What a useful warning. #ThanksGCC
brw_performance_monitor.c:153:1: warning: 'static' is not at beginning of
declaration [-Wold-style-declaration]
const static struct gl_perf_monitor_counter gen5_raw_chaps_counters[] = {
^
From: Ian Romanick ian.d.roman...@intel.com
I don't this opt_cmod_propagation_local ever used the fs_visitor.
brw_fs_cmod_propagation.cpp:52:40: warning: unused parameter 'v'
[-Wunused-parameter]
opt_cmod_propagation_local(fs_visitor *v, bblock_t *block)
Reviewed-by: Matt Turner matts...@gmail.com
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Hi all,
I'm in the process of extending this code to support arrays of arrays
but I'm struggling to find piglit tests that exercise it. Does anyone
know if there are tests designed to test this code path specifically?
Thanks,
Tim
___
mesa-dev mailing
On Feb 27, 2015 9:17 PM, Ben Widawsky b...@bwidawsk.net wrote:
On Fri, Feb 27, 2015 at 07:24:16PM +, Neil Roberts wrote:
The vertical alignment is ignored in the surface state for 1D array
textures so we can tightly pack them.
I've run this through Piglit and it doesn't cause any
Previously, we compared our new GS-out VUE map to the existing *VS*-out
VUE map, which is bogus.
This would mostly manifest as redundant dirty flagging where the GS is
in use but the VS and GS output layouts differ; but there is a scary
case where we would fail to flag a GS-out layout change if
On Fri, Feb 27, 2015 at 11:03 PM, Chris Forbes chr...@ijw.co.nz wrote:
Previously, we compared our new GS-out VUE map to the existing *VS*-out
VUE map, which is bogus.
This would mostly manifest as redundant dirty flagging where the GS is
in use but the VS and GS output layouts differ; but
https://bugs.freedesktop.org/show_bug.cgi?id=89364
Vinson Lee v...@freedesktop.org changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Patches 1 through 5 seem innocuous enough and are
Reviewed-by: Ian Romanick ian.d.roman...@intel.com
Do you have a tree somewhere that I could pull to make sure the others
don't break my build? :)
On 02/27/2015 04:47 PM, Brian Paul wrote:
---
src/mesa/main/compiler.h | 4
On Fri, Feb 27, 2015 at 6:50 PM, Ian Romanick i...@freedesktop.org wrote:
From: Ian Romanick ian.d.roman...@intel.com
I don't this opt_cmod_propagation_local ever used the fs_visitor.
I think I was probably using liveness information at some WIP stage.
Reviewed-by: Matt Turner
On Mon, Feb 9, 2015 at 6:30 PM, Emil Velikov emil.l.veli...@gmail.com wrote:
On 07/02/15 21:44, Sedat Dilek wrote:
Hi,
I was building mesa v10.4.4 with my llvm-toolchain v3.6.0rc2.
My build breaks like this...
...
Please cherry-pick...
commit ef7e0b39a24966526b102643523feac765771842
On Fri, Feb 27, 2015 at 07:24:16PM +, Neil Roberts wrote:
The vertical alignment is ignored in the surface state for 1D array
textures so we can tightly pack them.
I've run this through Piglit and it doesn't cause any regressions.
(This should probably be squashed into the patch
On 26/02/15 18:07, Brian Paul wrote:
On 02/26/2015 09:51 AM, Jose Fonseca wrote:
This is to enable the code to build with -Werror=vla in the short term,
and enable the code to build with MSVC2013 soon after.
---
include/c99_alloca.h | 45
It's unmaintained, and most likely broken: I use trace driver every now
and then, and everytime I do I need to fix it up.
It's also unused: identity_screen_create is never called.
Above all, it's dead weight: if identity driver had the infrastructure
for other pass-through drivers (like trace
Hi,
I experience a crash in the nouveau part of the mesa driver:
src/gallium/drivers/nouveau/nv30/nv30_vbo.c
in function:
void nv30_vbo_validate(struct nv30_context *nv30)
Sometimes, ve-vertex_buffer_index seems to be greater or equal
nv30-num_vtxbuf. If this happens, PUSH_RESRC crashes!
On Fri, Feb 27, 2015 at 7:16 AM, Jose Fonseca jfons...@vmware.com wrote:
Anything else?
Are the classic xlib and osmesa drivers useful given that they both
have Gallium alternatives these days?
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
On Sat, Jan 17, 2015 at 3:04 PM, Francisco Jerez curroje...@riseup.net wrote:
It's a wrapper around emit_buffer_surface_state with format=RAW, pitch=1,
rw=true and the remaining arguments ordered differently. There's no point in
having a separate vtbl pointer for that.
Yeah, I agree, that can
On Fri, Feb 27, 2015 at 10:16 AM, Jose Fonseca jfons...@vmware.com wrote:
- src/gallium/drivers/rbug: -- do people use it? does it work? it predates
apitrace GL + GUI, which sort of enables a lot of the same things, but
without the issue of having to hit moving target, which is what gallium
On 02/27/2015 10:05 AM, Matt Turner wrote:
On Fri, Feb 27, 2015 at 7:16 AM, Jose Fonseca jfons...@vmware.com wrote:
Anything else?
Are the classic xlib and osmesa drivers useful given that they both
have Gallium alternatives these days?
Yeah, I'd like to keep those.
-Brian
On Fri, Feb 27, 2015 at 7:27 AM, Samuel Iglesias Gonsalvez
sigles...@igalia.com wrote:
This could be the case of trying to compile a Mesa tarball (from 'make dist'
command) in a machine without Python interpreter installed. The autogenerated
files from mako templates were already created during
Ian Romanick i...@freedesktop.org writes:
IMAGE_HEIGHT is definitely used for glGetTexImage because that and
IMAGE_WIDTH allow you to get a subimage (before ARB_get_texture_sub_image).
I guess on glTexImage2D those could let you initialize a subregion of a
larger texture... kind of like
https://bugs.freedesktop.org/show_bug.cgi?id=89345
Brian Paul bri...@vmware.com changed:
What|Removed |Added
Status|NEW |RESOLVED
https://bugs.freedesktop.org/show_bug.cgi?id=89342
Brian Paul bri...@vmware.com changed:
What|Removed |Added
Status|NEW |RESOLVED
https://bugs.freedesktop.org/show_bug.cgi?id=89328
--- Comment #4 from Emil Velikov emil.l.veli...@gmail.com ---
(In reply to Samuel Iglesias from comment #3)
I wrote a patch (attached) that removes the python mako module check when
python is not installed in the system. If it needs to do
Should GL_ARB_gpu_shader_fp64 be marked as done for radeonsi in GL3.txt then? Or
is PIPE_SHADER_CAP_TGSI_DROUND_SUPPORTED a must as well (I don't think so and
maybe PIPE_SHADER_CAP_TGSI_DROUND_SUPPORTED could be enabled as well?).
Cheers,
Kai
Tom Stellard wrote on 27.02.2015 02:06:
---
Reviewed-by: Marek Olšák marek.ol...@amd.com
Marek
On Fri, Feb 27, 2015 at 3:30 AM, Tom Stellard thomas.stell...@amd.com wrote:
This adds SGPR count, VGPR count, shader size, LDS size, and scratch
usage to shader dumps.
---
src/gallium/drivers/radeonsi/si_shader.c | 18 --
From: Rob Clark robcl...@freedesktop.org
To lower two sided color, tgsi_lowering creates additional BCOLOR inputs
(matching up to the BCOLOR outputs on the vert shader). These inputs
should copy the interpolation state of their matching COLOR input.
Signed-off-by: Rob Clark
Signed-off-by: Ben Widawsky b...@bwidawsk.net
---
src/mesa/drivers/dri/i965/intel_batchbuffer.c | 16
1 file changed, 16 insertions(+)
diff --git a/src/mesa/drivers/dri/i965/intel_batchbuffer.c
b/src/mesa/drivers/dri/i965/intel_batchbuffer.c
index b0ebec7..e405918 100644
---
Before invalidating the RO state caches, we have to emit a PIPE_CONTROL...
The following is the best I can explain things as I understand them without
getting too far into the low-level details.
I believe the read only aspect of this is misleading. It just so happens that
the state caches are
https://bugs.freedesktop.org/show_bug.cgi?id=89363
Bug ID: 89363
Summary: build error - error: pointer of type 'void *' used in
arithmetic [-Werror=pointer-arith]
Product: Mesa
Version: git
Hardware: All
On Fri, Feb 27, 2015 at 10:22:10AM -0800, Ben Widawsky wrote:
From the comments in the code:
Called from intel_batchbuffer_flush before emitting MI_BATCHBUFFER_END and
sending it off.
This fixes a possible, unlikely infinite recursion in our batch flush path.
More
importantly it
On Fri, Feb 27, 2015 at 10:22 AM, Ben Widawsky
benjamin.widaw...@intel.com wrote:
I'm not really sure of the origins of the existing flag names. Modern docs
have
some slightly different names. Having the correct names makes it easier to
determine if existing PIPE_CONTROL flag settings are
Since commit 28f3f8d, indices generator take a start parameter. However, some
index values have been left to start at 0.
This fixes the glean/fbo test with the virgl driver.
---
src/gallium/auxiliary/indices/u_indices_gen.py | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff
From the comments in the code:
Called from intel_batchbuffer_flush before emitting MI_BATCHBUFFER_END and
sending it off.
This fixes a possible, unlikely infinite recursion in our batch flush path. More
importantly it allows me to add some code here.
The relevant part of the call chain
I'm not really sure of the origins of the existing flag names. Modern docs have
some slightly different names. Having the correct names makes it easier to
determine if existing PIPE_CONTROL flag settings are correct, as well as making
adding new PIPE_CONTROLs easier.
This originally came up while
https://bugs.freedesktop.org/show_bug.cgi?id=89364
Bug ID: 89364
Summary: c99_alloca.h:40:22: fatal error: alloca.h: No such
file or directory
Product: Mesa
Version: git
Hardware: x86-64 (AMD64)
OS: Linux
v2: Sent out the wrong patch original. This patches switches the order of
flushes, doing the generic flush before the CC_STATE, and the required
workaround flush afterwards
Signed-off-by: Ben Widawsky b...@bwidawsk.net
---
src/mesa/drivers/dri/i965/intel_batchbuffer.c | 17 +
1
On Fri, Feb 27, 2015 at 10:22:10AM -0800, Ben Widawsky wrote:
From the comments in the code:
Called from intel_batchbuffer_flush before emitting MI_BATCHBUFFER_END and
sending it off.
This fixes a possible, unlikely infinite recursion in our batch flush path.
More
importantly it
As we're gaining momentum cleanup Mesa code, I think it would help if we
also removed some stale components.
What do people feel about removing:
- src/mesa/drivers/windows/gdi -- the old SW rasterizer for Windows -- I
haven't used in a very long time, and given that the old SW rasterizer
is
And calculate the message response size based on the number of
components rather than the other way around. This simplifies their
interface somewhat and allows the caller to request a writeback
message with more than one vector component in SIMD4x2 mode.
---
src/mesa/drivers/dri/i965/brw_eu.h
This was telling the sampler to do texture fetches for *all* channels
in the non-constant surface index case, what could have reduced
throughput unnecessarily when some of the channels were disabled by
control flow.
---
src/mesa/drivers/dri/i965/brw_fs_generator.cpp | 12 ++--
The generate_untyped_*() methods do nothing useful other than calling
the corresponding function from brw_eu_emit.c. The calls to
brw_mark_surface_used() will go away too in a future commit.
---
src/mesa/drivers/dri/i965/brw_fs.h | 11 --
---
src/mesa/drivers/dri/i965/brw_eu.h | 19 ++--
src/mesa/drivers/dri/i965/brw_eu_emit.c | 58 ++--
src/mesa/drivers/dri/i965/brw_fs_generator.cpp | 55 +-
src/mesa/drivers/dri/i965/brw_vec4_generator.cpp | 37 ---
---
src/mesa/drivers/dri/i965/brw_fs_generator.cpp | 5 +++--
src/mesa/drivers/dri/i965/brw_fs_visitor.cpp | 2 +-
src/mesa/drivers/dri/i965/brw_vec4_generator.cpp | 6 --
src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp | 3 ++-
4 files changed, 10 insertions(+), 6 deletions(-)
diff
This is consistent with the untyped surface read opcode. From now on
all typed and untyped surface access opcodes will follow the same
pattern: src[0] will be the message payload, src[1] will be the
surface index and src[2] will be a control immediate (atomic operation
for atomic opcodes and
This doesn't actually enable untyped surface message sends from GRF
yet, the upcoming atomic counter and image intrinsic lowering code
will.
---
src/mesa/drivers/dri/i965/brw_vec4.cpp | 7 ---
src/mesa/drivers/dri/i965/brw_vec4_generator.cpp | 16 +++-
---
src/mesa/drivers/dri/i965/brw_defines.h | 2 +
src/mesa/drivers/dri/i965/brw_eu.h | 4 ++
src/mesa/drivers/dri/i965/brw_eu_emit.c | 70
src/mesa/drivers/dri/i965/brw_fs_generator.cpp | 4 ++
src/mesa/drivers/dri/i965/brw_shader.cpp
Hi Kai,
The patch only enables double support for compute shaders, which don't use TGSI.
There is no TGSI double support in radeonsi yet, so
ARB_gpu_shader_fp64 can't be marked as done.
Marek
On Fri, Feb 27, 2015 at 1:38 PM, Kai Wasserbäch
k...@dev.carbon-project.org wrote:
Should
On 02/27/2015 07:16 AM, Jose Fonseca wrote:
As we're gaining momentum cleanup Mesa code, I think it would help if we
also removed some stale components.
What do people feel about removing:
- src/mesa/drivers/windows/gdi -- the old SW rasterizer for Windows -- I
haven't used in a very long
This seems like a good idea to me.
Marek
On Fri, Feb 27, 2015 at 3:51 PM, Jose Fonseca jfons...@vmware.com wrote:
It's unmaintained, and most likely broken: I use trace driver every now
and then, and everytime I do I need to fix it up.
It's also unused: identity_screen_create is never
Hi,
This patch breaks the build for me:
CFLAGS=-g CXXFLAGS=$CFLAGS CC=ccache gcc CXX=ccache g++
./autogen.sh \
--prefix=/usr/local \
--with-dri-drivers=no \
--with-gallium-drivers=r600,radeonsi \
--enable-glx-tls \
--enable-debug \
--enable-shared-glapi \
--with-egl-platforms=x11,drm \
This is currently not a problem because the vec4 visitor happens to
mask out unused components from the destination, but it might become
an issue when we start using atomics without writeback message. In
any case it seems sensible to set it again here because the
consequences of setting the wrong
---
src/mesa/drivers/dri/i965/brw_fs_generator.cpp | 2 +-
src/mesa/drivers/dri/i965/brw_vec4_generator.cpp | 3 ++-
2 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_fs_generator.cpp
b/src/mesa/drivers/dri/i965/brw_fs_generator.cpp
index
Change brw_untyped_atomic() and brw_untyped_surface_read() to take the
surface index as a register instead of a constant and to use
brw_send_indirect_message() to emit the indirect variant of send with
a dynamically calculated message descriptor. This will be required to
support variable indexing
Hi Arno,
I think at this point the most helpful thing would be to get an
apitrace (https://github.com/apitrace/apitrace) with your fix in
place. Once you make the trace, change your fix to instead abort the
program, and replay the trace. This will allow us to look at the
precise call sequence
---
src/mesa/drivers/dri/i965/brw_defines.h| 4 +
src/mesa/drivers/dri/i965/brw_eu.h | 24 +++
src/mesa/drivers/dri/i965/brw_eu_emit.c| 169 +
src/mesa/drivers/dri/i965/brw_fs.cpp | 12 ++
---
src/mesa/drivers/dri/i965/brw_defines.h| 1 +
src/mesa/drivers/dri/i965/brw_eu.h | 7 +++
src/mesa/drivers/dri/i965/brw_eu_emit.c| 51 ++
src/mesa/drivers/dri/i965/brw_fs.cpp | 4 ++
On Fri, Feb 27, 2015 at 4:16 PM, Jose Fonseca jfons...@vmware.com wrote:
As we're gaining momentum cleanup Mesa code, I think it would help if we
also removed some stale components.
What do people feel about removing:
- src/mesa/drivers/windows/gdi -- the old SW rasterizer for Windows -- I
On Fri, Feb 27, 2015 at 10:16 AM, Jose Fonseca jfons...@vmware.com wrote:
- src/gallium/drivers/rbug: -- do people use it? does it work? it predates
apitrace GL + GUI, which sort of enables a lot of the same things, but
without the issue of having to hit moving target, which is what gallium
I like the idea as it should prevent future thrash. There are a couple
comments below.
On 02/26/2015 08:51 AM, Jose Fonseca wrote:
The main objective of this change is to enable Linux developers to use
more of C99 throughout Mesa, with confidence that the portions that need
to be built with
On 02/27/2015 08:16 AM, Jose Fonseca wrote:
As we're gaining momentum cleanup Mesa code, I think it would help if we
also removed some stale components.
What do people feel about removing:
- src/mesa/drivers/windows/gdi -- the old SW rasterizer for Windows -- I
haven't used in a very long
This could be the case of trying to compile a Mesa tarball (from 'make dist'
command) in a machine without Python interpreter installed. The autogenerated
files from mako templates were already created during tarball
generation.
In case of building from git without Python it is going to fail
Hello,
Bug 89328 [0] shows that Mesa releases will not build without python.
If there is no python installed in the system, the build's
configuration step is going to fail due to python mako module check.
The idea behind this patch is to disable the python mako module check
when python is not
On 02/26/2015 10:07 AM, Brian Paul wrote:
On 02/26/2015 09:51 AM, Jose Fonseca wrote:
This is to enable the code to build with -Werror=vla in the short term,
and enable the code to build with MSVC2013 soon after.
---
include/c99_alloca.h | 45
The vertical alignment is ignored in the surface state for 1D array
textures so we can tightly pack them.
I've run this through Piglit and it doesn't cause any regressions.
(This should probably be squashed into the patch entitled “i965/skl:
Fix the qpitch value”)
---
For some given GLSL IR like (+ (neg x) (* 1.2 x)), the try_emit_mad
function would see that one of the +'s sources was a negate expression
and set mul_negate = true without confirming that it was actually a
multiply.
Cc: 10.5 mesa-sta...@lists.freedesktop.org
Bugzilla:
On Fri, Feb 27, 2015 at 11:34 AM, Matt Turner matts...@gmail.com wrote:
We can safely propagate the conditional mod to an instruction with a
different type if the conditional mod does not involve comparing for
equality with zero (or probably NaN, but ignore that for now).
This is because -0.0
Commit 79daa510c added -Werror=pointer-arith to CFLAGS, which makes
arithmetic on void pointers an error.
See https://gcc.gnu.org/onlinedocs/gcc/Pointer-Arith.html
---
src/mapi/entry_x86-64_tls.h | 2 +-
src/mapi/entry_x86_tls.h| 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff
---
src/mesa/main/texgetimage.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/src/mesa/main/texgetimage.c b/src/mesa/main/texgetimage.c
index 24df5b6..f975c16 100644
--- a/src/mesa/main/texgetimage.c
+++ b/src/mesa/main/texgetimage.c
@@ -375,7 +375,7 @@
---
src/gallium/auxiliary/util/u_debug.c | 19 +++
src/gallium/auxiliary/util/u_debug.h | 3 +++
2 files changed, 22 insertions(+)
diff --git a/src/gallium/auxiliary/util/u_debug.c
b/src/gallium/auxiliary/util/u_debug.c
index f54fc3a..2d2d049 100644
---
---
src/glsl/opt_algebraic.cpp | 1 +
1 file changed, 1 insertion(+)
diff --git a/src/glsl/opt_algebraic.cpp b/src/glsl/opt_algebraic.cpp
index c3f3842..c6040bf 100644
--- a/src/glsl/opt_algebraic.cpp
+++ b/src/glsl/opt_algebraic.cpp
@@ -866,6 +866,7 @@
---
src/mesa/drivers/common/meta_tex_subimage.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/src/mesa/drivers/common/meta_tex_subimage.c
b/src/mesa/drivers/common/meta_tex_subimage.c
index 5ae12c8..bba2b4f 100644
--- a/src/mesa/drivers/common/meta_tex_subimage.c
+++
---
src/mesa/drivers/common/meta_blit.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/src/mesa/drivers/common/meta_blit.c
b/src/mesa/drivers/common/meta_blit.c
index 971a2ff..bb21642 100644
--- a/src/mesa/drivers/common/meta_blit.c
+++ b/src/mesa/drivers/common/meta_blit.c
@@ -133,6
Alternatively, it's probably safe (and faster) to just save/restore the
scissor in meta_begin/end. The _mesa_meta_BlitFramebuffer implementation
stashes everything else anyway.
--Jason
On Fri, Feb 27, 2015 at 12:29 PM, Jason Ekstrand ja...@jlekstrand.net
wrote:
Cc: 10.5
We can safely propagate the conditional mod to an instruction with a
different type if the conditional mod does not involve comparing for
equality with zero (or probably NaN, but ignore that for now).
This is because -0.0 and +0.0 are both test equal to zero, but their
integer representations do
Cc: 10.5 mesa-sta...@lists.freedesktop.org
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=89292
---
src/glsl/nir/nir_lower_vars_to_ssa.c| 34 +
src/mesa/drivers/common/meta_tex_subimage.c | 2 +-
2 files changed, 26 insertions(+), 10 deletions(-)
diff
According to the bspec for some reason the format of the maximum
number of threads field has changed from U8-2 to U8-1 for the PS.
I've run this through Piglit and it doesn't cause any regressions.
---
src/mesa/drivers/dri/i965/gen8_ps_state.c | 7 ++-
1 file changed, 6 insertions(+), 1
https://bugs.freedesktop.org/show_bug.cgi?id=89364
--- Comment #1 from Brian Paul bri...@vmware.com ---
The _MSC_VER check fails on MinGW. I'll post a patch...
--
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.
On Friday, February 27, 2015 02:04:47 PM Jose Fonseca wrote:
On 26/02/15 18:07, Brian Paul wrote:
[snip]
AFAIK, there's no zeroing version of alloca().
Yes, I also searched. And unfortunately inline functions can't be used
due to alloca semantics. I'm not sure if there's any
Reviewed-by: Brian Paul bri...@vmware.com
On 02/27/2015 12:48 PM, Matt Turner wrote:
Commit 79daa510c added -Werror=pointer-arith to CFLAGS, which makes
arithmetic on void pointers an error.
See
Cc: 10.5 mesa-sta...@lists.freedesktop.org
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=89292
---
src/mesa/drivers/common/meta_tex_subimage.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/src/mesa/drivers/common/meta_tex_subimage.c
This makes another part of the INTEL_DEBUG=shader_time code emittable
at arbitrary locations, rather than just at the end of the instruction
stream.
v2: Don't lose smear! Caught by Topi Pohjolainen.
Signed-off-by: Kenneth Graunke kenn...@whitecape.org
---
src/mesa/drivers/dri/i965/brw_fs.cpp |
To fix MinGW warning.
---
src/mesa/main/queryobj.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/src/mesa/main/queryobj.c b/src/mesa/main/queryobj.c
index e02969d2..0842b54 100644
--- a/src/mesa/main/queryobj.c
+++ b/src/mesa/main/queryobj.c
@@ -146,12 +146,13 @@ static
I broke this in commit 2881b123d. I must have misread i2b as b2i.
Cc: 10.5 mesa-sta...@lists.freedesktop.org
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=88246
---
src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
---
src/gallium/auxiliary/util/u_math.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/gallium/auxiliary/util/u_math.h
b/src/gallium/auxiliary/util/u_math.h
index 959f76e..5400fce 100644
--- a/src/gallium/auxiliary/util/u_math.h
+++
On Wed, Feb 25, 2015 at 11:45 PM, Timothy Arceri t_arc...@yahoo.com.au wrote:
V2: return true when var-type is unsized by max access is within valid range
---
src/glsl/linker.cpp | 89
++---
src/glsl/linker.h | 5 +++
2 files changed, 55
As with MSVC, include malloc.h but don't redefine alloca.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=89364
---
include/c99_alloca.h | 4
1 file changed, 4 insertions(+)
diff --git a/include/c99_alloca.h b/include/c99_alloca.h
index 6d96d06..7a81c50 100644
---
NEVER MIND THIS PATCH. I had a git-send-email fail
On Fri, Feb 27, 2015 at 12:26 PM, Jason Ekstrand ja...@jlekstrand.net
wrote:
Cc: 10.5 mesa-sta...@lists.freedesktop.org
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=89292
---
src/glsl/nir/nir_lower_vars_to_ssa.c| 34
Instead of emit_shader_time_write, we now do emit(SHADER_TIME_ADD(...)).
The advantage is that we can also insert a shader time write at an
arbitrary location in the instruction stream, rather than being
restricted to emitting at the end.
Signed-off-by: Kenneth Graunke kenn...@whitecape.org
---
Previously, we emitted the shader-time epilogue from emit_fb_writes(),
during the middle of looping through color regions (or emit_urb_writes
for the VS). This is duplicated several times and rather awkward.
I need to fix a bug in our FB write handling, and it will be a lot
easier if we move
We used to loop over all color attachments, and emit FB writes for each
one, even if the shader didn't write to a corresponding output variable.
Those color attachments would be filled with garbage (undefined values).
Football Manager binds a framebuffer with 4 color attachments, but draws
to it
This makes another part of the INTEL_DEBUG=shader_time code emittable
at arbitrary locations, rather than just at the end of the instruction
stream.
Signed-off-by: Kenneth Graunke kenn...@whitecape.org
---
src/mesa/drivers/dri/i965/brw_fs.cpp | 14 --
This patch is
Reviewed-by: Ian Romanick ian.d.roman...@intel.com
On 02/27/2015 11:34 AM, Matt Turner wrote:
I broke this in commit 2881b123d. I must have misread i2b as b2i.
Cc: 10.5 mesa-sta...@lists.freedesktop.org
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=88246
---
https://bugs.freedesktop.org/show_bug.cgi?id=89363
Frederik vom Hofe frederik.h...@gmail.com changed:
What|Removed |Added
CC|
With the tiny nit below fixed, this patch is
Reviewed-by: Ian Romanick ian.d.roman...@intel.com
On 02/27/2015 11:34 AM, Matt Turner wrote:
For some given GLSL IR like (+ (neg x) (* 1.2 x)), the try_emit_mad
function would see that one of the +'s sources was a negate expression
and set
On 02/27/2015 11:34 AM, Matt Turner wrote:
We can safely propagate the conditional mod to an instruction with a
different type if the conditional mod does not involve comparing for
equality with zero (or probably NaN, but ignore that for now).
This is because -0.0 and +0.0 are both test
1 - 100 of 144 matches
Mail list logo
