On 11/27/2013 03:28 PM, Petri Latvala wrote:
Third version of this patch series sent in full
Ping? Comments, NAKs, ACKs...?
--
Petri Latvala
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
On Die, 2013-12-17 at 03:31 +0100, Marek Olšák wrote:
From: Marek Olšák marek.ol...@amd.com
This series is
Reviewed-by: Michel Dänzer michel.daen...@amd.com
Does this address bugs such as
https://bugs.freedesktop.org/show_bug.cgi?id=72685 and
https://bugzilla.kernel.org/show_bug.cgi?id=66981
Because of the combinatorial explosion of different image built-ins
with different image dimensionalities and base data types, enumerating
all the 242 possibilities would be annoying and a waste of .text
space. Instead use a special path in the built-in builder that loops
over all the known image
It doesn't fix the corruption in Sanctuary. I haven't been able to
reproduce the GPU crashes though (I don't have Serious Sam 3 or
Skyrim). I agree it should be disabled by default if we don't find a
fix quickly.
Marek
On Tue, Dec 17, 2013 at 9:44 AM, Michel Dänzer mic...@daenzer.net wrote:
On
From: Marek Olšák marek.ol...@amd.com
This may fix the GPU crashes.
---
src/gallium/drivers/radeonsi/si_state.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/src/gallium/drivers/radeonsi/si_state.c
b/src/gallium/drivers/radeonsi/si_state.c
index c1107c6..5c18538 100644
---
From: Marek Olšák marek.ol...@amd.com
Also needed for the DB in-place decompression according to hw docs.
---
src/gallium/drivers/radeonsi/si_state.c | 11 ---
1 file changed, 8 insertions(+), 3 deletions(-)
diff --git a/src/gallium/drivers/radeonsi/si_state.c
The dri2 state tracker is checking for driver support before enabling
dri2ImageExtension version 7. This commit adds a check that also the
kernel driver supports fd sharing through prime.
Note that this adds a libdrm dependency on dri2.c.
Signed-off-by: Thomas Hellstrom thellst...@vmware.com
---
On Fri, Oct 11, 2013 at 10:48 PM, Ian Romanick i...@freedesktop.org wrote:
Carl,
Can you look at this patch and Erik's follow-up patch? You (still) know
the glcpp much better than any of the rest of us.
(Carl is currently out of town, so I know his response will be slow...)
I guess slow
On Tue, Dec 17, 2013 at 6:49 AM, Marek Olšák mar...@gmail.com wrote:
From: Marek Olšák marek.ol...@amd.com
This may fix the GPU crashes.
Reviewed-by: Alex Deucher alexander.deuc...@amd.com
---
src/gallium/drivers/radeonsi/si_state.c | 2 ++
1 file changed, 2 insertions(+)
diff --git
On Tue, Dec 17, 2013 at 7:54 AM, Marek Olšák mar...@gmail.com wrote:
From: Marek Olšák marek.ol...@amd.com
Also needed for the DB in-place decompression according to hw docs.
Makes sense.
Reviewed-by: Alex Deucher alexander.deuc...@amd.com
---
src/gallium/drivers/radeonsi/si_state.c | 11
Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=72708
It seems to me that the Intel code that uses this SSE4.1 function
is still buggy, as it has no runtime check - would it not crash
if built on a SSE4-capable system but used with a lower-class cpu?
i965 systems = LGA775 = Pentium4 without
The preprocessor currently accepts multiple else/elif-groups
per if-section. The GLSL-preprocessor is defined by the C++
specification, which defines the following parse-rule:
if-section:
if-group elif-groups(opt) else-group(opt) endif-line
This clearly only allows a single else-group,
Hi all,
Is there a way to see the machine code that is generated by the GLSL
compiler for all GPU instruction sets? For example, I would like to know if
the optimizer optimizes certain (equivalent) constructs (or not), and avoid
them if possible. I know there is a lot to optimization on GPUs that
On Tue, Dec 17, 2013 at 7:54 AM, Marek Olšák mar...@gmail.com wrote:
From: Marek Olšák marek.ol...@amd.com
Also needed for the DB in-place decompression according to hw docs.
Published hw docs?
regards,
--
Sylvain
___
mesa-dev mailing list
v2: use fewer if statements and functional tricks instead of single-use method,
suggested by Francisco Jerez
squash two small patches into one
Signed-off-by: Jan Vesely jan.ves...@rutgers.edu
---
Hi,
this is v2 of the first two patches incorporating Francisco's comments,
i.e. it's the
From: Marek Olšák marek.ol...@amd.com
Also needed for the DB in-place decompression according to hw docs.
Published hw docs?
regards,
--
Sylvain
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
On 17 December 2013 02:10, Francisco Jerez curroje...@riseup.net wrote:
Because of the combinatorial explosion of different image built-ins
with different image dimensionalities and base data types, enumerating
all the 242 possibilities would be annoying and a waste of .text
space. Instead
On Tue, Dec 17, 2013 at 09:57:31AM -0600, Patrick Baggett wrote:
Hi all,
Is there a way to see the machine code that is generated by the GLSL
compiler for all GPU instruction sets? For example, I would like to know if
the optimizer optimizes certain (equivalent) constructs (or not), and
On 17 December 2013 08:46, Tom Stellard t...@stellard.net wrote:
On Tue, Dec 17, 2013 at 09:57:31AM -0600, Patrick Baggett wrote:
Hi all,
Is there a way to see the machine code that is generated by the GLSL
compiler for all GPU instruction sets? For example, I would like to know
if
I don't think so.
Marek
On Tue, Dec 17, 2013 at 5:10 PM, Sylvain BERTRAND sylw...@legeek.net wrote:
From: Marek Olšák marek.ol...@amd.com
Also needed for the DB in-place decompression according to hw docs.
Published hw docs?
regards,
--
Sylvain
ST_DEBUG=tgsi ... is also useful. It dumps all shaders generated by
mesa_to_tgsi and glsl_to_tgsi and it's easier to read than the GLSL
IR.
Marek
On Tue, Dec 17, 2013 at 5:46 PM, Tom Stellard t...@stellard.net wrote:
On Tue, Dec 17, 2013 at 09:57:31AM -0600, Patrick Baggett wrote:
Hi all,
Is
On Sat, Dec 14, 2013 at 8:28 PM, Rob Clark robdcl...@gmail.com wrote:
From: Rob Clark robcl...@freedesktop.org
It seems that over time, code related to finding driver name, dealing
with pci-id table, etc, has been copy/pasted everywhere it was needed.
Which is lame. And annoying if you have
This argument was carrying the name of the shader target (as a
string). We can get this just as easily by calling
_mesa_glsl_shader_target_name().
---
src/glsl/linker.cpp | 9 +
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/src/glsl/linker.cpp b/src/glsl/linker.cpp
index
---
src/mesa/main/shaderobj.h | 15 ---
1 file changed, 15 deletions(-)
diff --git a/src/mesa/main/shaderobj.h b/src/mesa/main/shaderobj.h
index de1c9fc..7245c5e 100644
--- a/src/mesa/main/shaderobj.h
+++ b/src/mesa/main/shaderobj.h
@@ -118,21 +118,6 @@
This patch replaces the following pattern:
foo bar[MESA_SHADER_TYPES] = {
...
};
With:
foo bar[] = {
...
};
STATIC_ASSERT(Elements(bar) == MESA_SHADER_TYPES);
This way, when a new shader type is added in a future version of Mesa,
we will get a compile error to
On 17 December 2013 11:07, Patrick Baggett baggett.patr...@gmail.comwrote:
On Tue, Dec 17, 2013 at 10:59 AM, Paul Berry stereotype...@gmail.comwrote:
On 17 December 2013 08:46, Tom Stellard t...@stellard.net wrote:
On Tue, Dec 17, 2013 at 09:57:31AM -0600, Patrick Baggett wrote:
Hi all,
On 12/17/2013 11:50 AM, Brian Paul wrote:
On 12/17/2013 12:28 PM, Paul Berry wrote:
[snip]
How about this idea instead: rather than use function overloading to
distinguish between the two meanings of _mesa_glsl_shader_target_name(),
have two functions with separate names, e.g.:
const char
On 17 December 2013 10:51, Brian Paul bri...@vmware.com wrote:
On 12/17/2013 11:23 AM, Paul Berry wrote:
We already have a function for converting a shader type index to a
string: _mesa_glsl_shader_target_name().
---
src/glsl/link_atomics.cpp | 8 +++-
src/glsl/linker.cpp |
On 12/17/2013 12:28 PM, Paul Berry wrote:
On 17 December 2013 10:51, Brian Paul bri...@vmware.com
mailto:bri...@vmware.com wrote:
On 12/17/2013 11:23 AM, Paul Berry wrote:
We already have a function for converting a shader type index to a
string:
On Sat, Nov 23, 2013 at 4:10 PM, Marek Olšák mar...@gmail.com wrote:
On Sat, Nov 23, 2013 at 10:23 PM, Mark Mueller markkmuel...@gmail.com
wrote:
On Sat, Nov 23, 2013 at 2:26 AM, Marek Olšák mar...@gmail.com wrote:
[...]
MESA_FORMAT_RGBA1555_REV,
I don't think you can
On 12/17/2013 11:23 AM, Paul Berry wrote:
We already have a function for converting a shader type index to a
string: _mesa_glsl_shader_target_name().
---
src/glsl/link_atomics.cpp | 8 +++-
src/glsl/linker.cpp | 16 ++--
2 files changed, 9 insertions(+), 15
Broadwell allows us to specify an arbitrary value for QPitch, rather
than baking a specific formula into the hardware and requiring software
to lay things out to match. The only restriction is that the software
provided QPitch needs to be large enough so successive array slices do
not overlap.
Previously, _mesa_glsl_shader_target_name() had an overload for GLenum
and an overload for the gl_shader_type enum, each of which behaved
differently. However, since GLenum is a synonym for unsigned int, and
unsigned ints are often used in place of gl_shader_type (e.g. in loop
indices), there was
On 17 December 2013 13:05, Kenneth Graunke kenn...@whitecape.org wrote:
Broadwell allows us to specify an arbitrary value for QPitch, rather
than baking a specific formula into the hardware and requiring software
to lay things out to match. The only restriction is that the software
provided
On 2 December 2013 11:31, Francisco Jerez curroje...@riseup.net wrote:
diff --git a/src/mesa/drivers/dri/i965/brw_wm.c
b/src/mesa/drivers/dri/i965/brw_wm.c
index bc1480c..b745d8f 100644
--- a/src/mesa/drivers/dri/i965/brw_wm.c
+++ b/src/mesa/drivers/dri/i965/brw_wm.c
@@ -165,6 +165,7 @@
We already have a function for converting a shader type index to a
string: _mesa_glsl_shader_target_name().
---
src/glsl/link_atomics.cpp | 8 +++-
src/glsl/linker.cpp | 16 ++--
2 files changed, 9 insertions(+), 15 deletions(-)
diff --git a/src/glsl/link_atomics.cpp
Only a Mesa bug could cause this function to be called with an
out-of-range index, so raise an assertion if that ever happens.
---
src/mesa/program/program.h | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/src/mesa/program/program.h b/src/mesa/program/program.h
index
On 12/17/2013 11:23 AM, Paul Berry wrote:
---
src/mesa/main/shaderobj.h | 15 ---
1 file changed, 15 deletions(-)
diff --git a/src/mesa/main/shaderobj.h b/src/mesa/main/shaderobj.h
index de1c9fc..7245c5e 100644
--- a/src/mesa/main/shaderobj.h
+++ b/src/mesa/main/shaderobj.h
@@
On 2 December 2013 11:31, Francisco Jerez curroje...@riseup.net wrote:
diff --git a/src/mesa/drivers/dri/i965/brw_program.c
b/src/mesa/drivers/dri/i965/brw_program.c
index 9a517be..a494bc2 100644
--- a/src/mesa/drivers/dri/i965/brw_program.c
+++ b/src/mesa/drivers/dri/i965/brw_program.c
@@
Found while tracking down memory leaks in VDPAU playback
Reviewed-by: Tom Stellard thomas.stell...@amd.com
CC: 10.0 mesa-sta...@lists.freedesktop.org
---
src/gallium/drivers/r600/r600_pipe.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/src/gallium/drivers/r600/r600_pipe.c
Most of these fixes target radeon (both EG and SI), but some also help
generic clover and also vdpau playback.
v2: Remove an unnecessary null check in patch 4 of 8
CC: 10.0 mesa-sta...@lists.freedesktop.org
Aaron Watry (8):
clover: Remove unused variable
pipe_loader/sw: close dev-lib when
v2: Remove unnecessary null pointer check
CC: 10.0 mesa-sta...@lists.freedesktop.org
---
src/gallium/drivers/r600/evergreen_compute.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/src/gallium/drivers/r600/evergreen_compute.c
b/src/gallium/drivers/r600/evergreen_compute.c
index
Previously we were creating a new LLVMContext every time that we called
radeon_llvm_parse_bitcode, which caused us to leak the context every time
that we compiled a CL program.
Sadly, we can't dispose of the LLVMContext at the point that it was being
created because evergreen_launch_grid (and
Reviewed-by: Tom Stellard thomas.stell...@amd.com
CC: 10.0 mesa-sta...@lists.freedesktop.org
---
src/gallium/state_trackers/clover/llvm/invocation.cpp | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/gallium/state_trackers/clover/llvm/invocation.cpp
Reviewed-by: Tom Stellard thomas.stell...@amd.com
CC: 10.0 mesa-sta...@lists.freedesktop.org
---
src/gallium/drivers/r600/evergreen_compute.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/gallium/drivers/r600/evergreen_compute.c
Prevents a memory leak.
Reviewed-by: Tom Stellard thomas.stell...@amd.com
CC: 10.0 mesa-sta...@lists.freedesktop.org
---
src/gallium/auxiliary/pipe-loader/pipe_loader_sw.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/src/gallium/auxiliary/pipe-loader/pipe_loader_sw.c
Prevents a potential memory leak found when tracking down something else.
Reviewed-by: Christian König christian.koe...@amd.com
Reviewed-by: Tom Stellard thomas.stell...@amd.com
CC: 10.0 mesa-sta...@lists.freedesktop.org
---
src/gallium/state_trackers/vdpau/device.c | 1 +
1 file changed, 1
Reviewed-by: Tom Stellard thomas.stell...@amd.com
CC: 10.0 mesa-sta...@lists.freedesktop.org
---
src/gallium/drivers/radeon/radeon_llvm_util.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/src/gallium/drivers/radeon/radeon_llvm_util.c
b/src/gallium/drivers/radeon/radeon_llvm_util.c
index
On 12/17/2013 02:32 PM, Paul Berry wrote:
Previously, _mesa_glsl_shader_target_name() had an overload for GLenum
and an overload for the gl_shader_type enum, each of which behaved
differently. However, since GLenum is a synonym for unsigned int, and
unsigned ints are often used in place of
The type_valid local was set to true and never changed.
---
src/mesa/main/glformats.c |4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/src/mesa/main/glformats.c b/src/mesa/main/glformats.c
index 740faa8..1ab8b23 100644
--- a/src/mesa/main/glformats.c
+++
intelEmitCopyBlit uses a signed 16-bit integer to represent
buffer pitch, so it can only handle buffer pitches 32k.
This patch fixes assertion failure in depth_texture_mipmap.test
in Khronos' OpenGL CTS. But, the test still fails due to
GL_OUT_OF_MEMORY error in glTexImage2D().
Cc:
From: Dave Airlie airl...@redhat.com
This is just a simple implementation that stores the extra values into the
DRIimage
struct and just uses the fd importer. I haven't looked into what is required
to import YUV or deal with the extra parameters.
Signed-off-by: Dave Airlie airl...@redhat.com
From: Dave Airlie airl...@redhat.com
Before I cut-n-paste this a 3rd time lets consolidate it.
Signed-off-by: Dave Airlie airl...@redhat.com
---
src/gallium/state_trackers/dri/drm/dri2.c | 81 +--
1 file changed, 35 insertions(+), 46 deletions(-)
diff --git
José, is it really worth adding a new cap? The only way to hit both
pipe-clear and clear_with_quad for depth and stencil, respectively,
is to have a partial stencil writemask.
Marek
On Fri, Dec 13, 2013 at 5:46 PM, Jose Fonseca jfons...@vmware.com wrote:
So, if this provides a significant
On Tue, Dec 17, 2013 at 12:19 PM, Mark Mueller markkmuel...@gmail.comwrote:
On Sat, Nov 23, 2013 at 4:10 PM, Marek Olšák mar...@gmail.com wrote:
On Sat, Nov 23, 2013 at 10:23 PM, Mark Mueller markkmuel...@gmail.com
wrote:
On Sat, Nov 23, 2013 at 2:26 AM, Marek Olšák
On 12/17/2013 06:50 PM, Mark Mueller wrote:
On Tue, Dec 17, 2013 at 12:19 PM, Mark Mueller markkmuel...@gmail.com
mailto:markkmuel...@gmail.com wrote:
On Sat, Nov 23, 2013 at 4:10 PM, Marek Olšák mar...@gmail.com
mailto:mar...@gmail.com wrote:
On Sat, Nov 23,
On 12/10/2013 11:25 PM, Kenneth Graunke wrote:
This replaces the brw_eu_emit.c layer for Broadwell. It will be
used by both the vector and scalar shader backends.
v2: Port to use the C-based instruction representation.
Signed-off-by: Kenneth Graunke kenn...@whitecape.org
---
On 12/10/2013 11:25 PM, Kenneth Graunke wrote:
[snip]
+static inline void
+gen8_set_src1_3src_subreg_nr(struct gen8_instruction *inst, unsigned v)
+{
+ assert((v ~0x7) == 0);
+
+ gen8_instruction_set_bits(inst, 95, 94, v 0x3f);
+ gen8_instruction_set_bits(inst, 96, 96, v 2);
+}
Signed-off-by: Timothy Arceri t_arc...@yahoo.com.au
---
src/glsl/ast_to_hir.cpp | 45 -
1 file changed, 24 insertions(+), 21 deletions(-)
diff --git a/src/glsl/ast_to_hir.cpp b/src/glsl/ast_to_hir.cpp
index 3bc181e..a7aa4c7 100644
---
59 matches
Mail list logo
