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
---
src/mesa/drivers/dri/i
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 emit
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 u
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
---
src/mesa/drivers/dri/i965/brw_fs.cpp | 14 --
src/mesa/drivers/dri/i965/brw_fs.h | 2 +-
2 files
https://bugs.freedesktop.org/show_bug.cgi?id=89328
--- Comment #3 from Samuel Iglesias ---
Created attachment 113857
--> https://bugs.freedesktop.org/attachment.cgi?id=113857&action=edit
remove mako check when python is not installed
> The distribution tarballs (should) provide all the auto-ge
On Thursday, February 26, 2015 12:09:57 PM Jose Fonseca wrote:
> MSVC 2008 (shipped with Windows SDK 7.0.7600) is the oldest we
> need to support. At least on llvmpipe, gallium/auxiliary, and util
> modules. For the remaining modules (particular all OpenGL specific
> code) can be built with MSVC
On Thursday, February 26, 2015 04:51:21 PM 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
>
> src/glsl/ni
https://bugs.freedesktop.org/show_bug.cgi?id=88907
Tapani Pälli changed:
What|Removed |Added
Attachment #113390|0 |1
is obsolete|
On Fri, Feb 27, 2015 at 12:06:00AM -0800, Kenneth Graunke wrote:
> 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
> ---
> src/mesa/drivers/dri/i965/brw_fs.
On Fri, Feb 27, 2015 at 12:05:59AM -0800, Kenneth Graunke wrote:
> 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
Tom Stellard writes:
> This should be done by the frontend for devices that support this
> extension.
Reviewed-by: Francisco Jerez
> ---
> src/gallium/state_trackers/clover/llvm/invocation.cpp | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/src/gallium/state_trackers/clover/llvm/invoc
On Fri, Feb 27, 2015 at 12:06:01AM -0800, Kenneth Graunke wrote:
> 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
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:
> ---
> src/
Ian Romanick 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 doing glTexImage2D(.
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
s
https://bugs.freedesktop.org/show_bug.cgi?id=89342
Brian Paul changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://bugs.freedesktop.org/show_bug.cgi?id=89345
Brian Paul changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
From: Rob Clark
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
---
src/gallium/auxiliary/tgsi/tgsi_lowerin
Reviewed-by: Marek Olšák
Marek
On Fri, Feb 27, 2015 at 3:30 AM, Tom Stellard 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 --
> 1 file changed, 12 insertions(+), 6 de
https://bugs.freedesktop.org/show_bug.cgi?id=89328
--- Comment #4 from Emil Velikov ---
(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 something with
> python, it
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!
H
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 and
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 s
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 anywa
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 ins
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 4e695f5..48ee
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
---
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
---
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 numbe
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/d
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 ++--
src/mesa/d
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_fs_generat
---
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 ---
4
---
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_f
---
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 ++
src/mesa/drivers/dri/i965/brw_fs_g
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
wrote:
> Should GL_ARB_gpu_shader_fp64 be marked as do
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 ver
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 th
This seems like a good idea to me.
Marek
On Fri, Feb 27, 2015 at 3:51 PM, Jose Fonseca 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 called.
>
> Above all,
On Fri, Feb 27, 2015 at 10:16 AM, Jose Fonseca 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
> interfaces are
F
On Fri, Feb 27, 2015 at 4:16 PM, 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
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/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
>> +
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 time,
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
On Fri, Feb 27, 2015 at 10:16 AM, Jose Fonseca 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
> interfaces are
A
On Sat, Jan 17, 2015 at 3:04 PM, Francisco Jerez 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 go.
Reviewed-by:
On Fri, Feb 27, 2015 at 7:16 AM, Jose Fonseca 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
http://lists.freedes
On 02/27/2015 10:05 AM, Matt Turner wrote:
On Fri, Feb 27, 2015 at 7:16 AM, Jose Fonseca 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
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 tarball
> generat
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
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 for
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
Signed-off-by: Ben Widawsky
---
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
--- a/src/mesa/drivers/d
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
> important
On Fri, Feb 27, 2015 at 10:22 AM, Ben Widawsky
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 correct, as well as
> maki
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
---
src/mesa/drivers/dri/i965/intel_batchbuffer.c | 17 +
1 file changed, 17 in
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 --gi
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
OS:
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 (A
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
> important
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
---
src/mesa/drivers/dri/i965/brw_fs.cpp | 24 +-
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 delet
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”)
---
src/mesa/drivers/dri/i965/b
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 n
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
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=89315
Bugzilla:
I broke this in commit 2881b123d. I must have misread i2b as b2i.
Cc: 10.5
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 a/src/mesa/drivers/dri/i965/brw_vec4_visito
On Fri, Feb 27, 2015 at 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
https://bugs.freedesktop.org/show_bug.cgi?id=89364
--- Comment #1 from Brian Paul ---
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.
__
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 --
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 C-prepr
---
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
+++ b/src/gallium/auxiliary/util/u_math
On Wed, Feb 25, 2015 at 11:45 PM, Timothy Arceri 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 insertions(+),
---
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 @@ get_tex_rgba_uncompr
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
--- a/include/c99_alloc
---
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
--- a/src/gallium/auxiliary/u
---
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 @@ ir_algebraic_visitor::handle_expression(ir_
---
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
+++ b/src
---
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 +133,
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
Reviewed-by: Brian Paul
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
https://urldefense.proofpoint.com/v2/url?u=https-3A__gcc.gnu.org_onlinedocs_gcc_Pointer-2DArith.html&d=AwIGaQ&c=Sqc
Cc: 10.5
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 --git a/src/glsl/nir/nir_lower_va
Cc: 10.5
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
b/src/mesa/drivers/common/meta_tex_subimage.c
index 5ae12c
NEVER MIND THIS PATCH. I had a git-send-email fail
On Fri, Feb 27, 2015 at 12:26 PM, Jason Ekstrand
wrote:
> Cc: 10.5
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=89292
> ---
> src/glsl/nir/nir_lower_vars_to_ssa.c| 34
> +
> src/mesa/drivers/co
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
wrote:
> Cc: 10.5
> Bugzilla: https://bugs.freedesktop.org/s
https://bugs.freedesktop.org/show_bug.cgi?id=89363
Frederik vom Hofe changed:
What|Removed |Added
CC||frederik.h...@gmail.com
--
You are
This patch is
Reviewed-by: Ian Romanick
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
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=88246
> ---
> src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp | 2 +-
> 1
With the tiny nit below fixed, this patch is
Reviewed-by: Ian Romanick
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 mul_negate = true without con
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
On Fri, Feb 27, 2015 at 11:15:35AM -0800, Kenneth Graunke wrote:
> 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: Ken
Sorry, this didn't pop up when I built it here. And I'm afraid I won't have
time to look into this today, and possibly the weekend.
If there's not an obvious fix feel free to push a commit commiting out the
.MSVC2013_COMPAT_*FLAGS= in configure.ac
I'll act on other reviews too as soon as I ca
Thanks for figuring out how to do this properly.
Reviewed-by: Jason Ekstrand
On Fri, Feb 27, 2015 at 12:06 AM, Kenneth Graunke
wrote:
> 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 col
I think this is fine now.
We need to update SCons to be less pedantic about the
-Wdeclaration-after-statement / -Wpointer-arith this on a per-directory-basis,
like my recent configure.ac change.
Jose
From: mesa-dev on behalf of Brian Paul
Sent: 27 F
Thanks!
From: mesa-dev on behalf of Matt
Turner
Sent: 27 February 2015 19:48
To: mesa-dev@lists.freedesktop.org
Subject: [Mesa-dev] [PATCH] mapi: Don't rely on GNU void pointer arithmetic.
Commit 79daa510c added -Werror=pointer-arith to CFLAGS, which mak
On 27/02/15 15:16, 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 lon
On Fri, Feb 27, 2015 at 12:07 PM, Brian Paul wrote:
> ---
> 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/m
From: Ian Romanick
It appears that all the other instructions that need it already use it.
This one just got missed.
Signed-off-by: Ian Romanick
Cc: "10.5"
Cc: Jason Ekstrand
---
src/mesa/drivers/dri/i965/brw_fs_nir.cpp | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/
1 - 100 of 144 matches
Mail list logo
