Am 18.08.2013 14:20, schrieb Emil Velikov:
On 18/08/13 12:31, Christian König wrote:
Am 17.08.2013 23:51, schrieb Emil Velikov:
Otherwise we risk causing memory corruption.
v2: forgot the mutex_unlock()
Signed-off-by: Emil Velikov emil.l.veli...@gmail.com
NAK. Failing is actually not
Am 19.08.2013 18:00, schrieb Emil Velikov:
Not seen in the wild yet, but seems like a reasonable thing to do.
[suggested by Christian]
Signed-off-by: Emil Velikov emil.l.veli...@gmail.com
Reviewed-by: Christian König christian.koe...@amd.com
Do you have commit access? And by the way I have
Am 19.08.2013 18:17, schrieb Emil Velikov:
On 19/08/13 17:09, Christian König wrote:
Am 19.08.2013 18:00, schrieb Emil Velikov:
Not seen in the wild yet, but seems like a reasonable thing to do.
[suggested by Christian]
Signed-off-by: Emil Velikov emil.l.veli...@gmail.com
Reviewed-by:
On Sat, Aug 10, 2013 at 8:31 PM, Marek Olšák mar...@gmail.com wrote:
MSAA was tested by one user on RS690 and it works for him with color
compression (CMASK) disabled. Our theory is that his chipset lacks CMASK RAM.
Since we don't have hardware documentation about which chipsets actually have
On 20 August 2013 01:20, Kenneth Graunke kenn...@whitecape.org wrote:
On 08/18/2013 05:58 PM, Kenneth Graunke wrote:
On 08/15/2013 10:52 PM, Paul Berry wrote:
On 14 August 2013 18:55, Kenneth Graunke kenn...@whitecape.org
mailto:kenn...@whitecape.org** wrote:
Now that we have the
---
src/mesa/main/get.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/mesa/main/get.c b/src/mesa/main/get.c
index 09b008a..4f6f59a 100644
--- a/src/mesa/main/get.c
+++ b/src/mesa/main/get.c
@@ -709,7 +709,7 @@ find_custom_value(struct gl_context *ctx, const struct
https://bugs.freedesktop.org/show_bug.cgi?id=68296
--- Comment #1 from Brian Paul bri...@vmware.com ---
Which driver are you using (the output of glxinfo would be helpful)?
--
You are receiving this mail because:
You are the assignee for the bug.
___
https://bugs.freedesktop.org/show_bug.cgi?id=68296
--- Comment #2 from Rafael Antognolli antogno...@gmail.com ---
I can't find it on the glxinfo output, but I'm attaching it anyway.
Is there any other way to know, or any other debug that I can attach?
--
You are receiving this mail because:
https://bugs.freedesktop.org/show_bug.cgi?id=68296
--- Comment #3 from Rafael Antognolli antogno...@gmail.com ---
Created attachment 84345
-- https://bugs.freedesktop.org/attachment.cgi?id=84345action=edit
glxinfo output
--
You are receiving this mail because:
You are the assignee for the
Op 20-08-13 02:05, Ian Romanick schreef:
Mesa 9.2 release candidate 1 is now available for testing.
The tag in the GIT repository for Mesa 9.2-rc1 is 'mesa-9.2-rc1'.
Mesa 9.2 release candidate 1 is available for download at
ftp://freedesktop.org/pub/mesa/9.2/
md5sums:
Hi Ian and All,
I tested the release candidate's llvmpipe OS Mesa on VTK's regression
suite. it did fairly well 99% pass, however there are some regressions
and segv's compared to OS Mesa in 9.1.5, which passes 100%. (data below)
There's a volunteer who graciously runs nightly regression
On 18 August 2013 22:15, Kenneth Graunke kenn...@whitecape.org wrote:
SURF_INDEX_DRAW() has been the identity function since the dawn of time,
and both the shader code and binding table upload code relied on that,
simply using X rather than SURF_INDEX_DRAW(X).
Even if that continues to be
On 18 August 2013 18:06, Kenneth Graunke kenn...@whitecape.org wrote:
This was invaluable when debugging the global copy propagation
algorithm. We may as well commit it in case someone needs to print
out the sets in the future.
Signed-off-by: Kenneth Graunke kenn...@whitecape.org
On Tue, Aug 20, 2013 at 8:54 AM, Maarten Lankhorst
maarten.lankho...@canonical.com wrote:
1. There is a new gallium based osmesa, which doesn't work correctly with
wine. My testcase is running opengl32_test from wine/dlls/opengl32/tests.
I've pushed a few fixes, but gave up after I was still
This series constitutes the initial geometry shader support for i965
Gen7 (Ivy Bridge) and Gen7.5 (Haswell).
Basic functionality works, but I haven't turned it on yet because the
following tasks still need to be done:
- Get sampling to work
- Support EndPrimitive()
- Support gl_PrimitiveID
This patch extracts the following logic from
validate_vertex_shader_executable():
(a) Generate an error if the shader writes to both gl_ClipDistance and
gl_ClipVertex.
(b) Record whether the shader writes to gl_ClipDistance in
gl_shader_program for use by the back-end.
(c) Record the
---
src/mesa/program/prog_instruction.h | 8
src/mesa/program/program.h | 8
2 files changed, 16 insertions(+)
diff --git a/src/mesa/program/prog_instruction.h
b/src/mesa/program/prog_instruction.h
index be22181..b9604e5 100644
---
---
src/mesa/drivers/dri/i965/brw_program.h | 8
src/mesa/drivers/dri/i965/brw_shader.cpp | 2 +-
src/mesa/drivers/dri/i965/brw_shader.h | 7 ++-
src/mesa/drivers/dri/i965/brw_vec4.h | 12 ++--
src/mesa/drivers/dri/i965/brw_vs.h | 8
5 files changed,
Otherwise any GS that requires lowering (e.g. one that uses
gl_ClipDistance as an input or output) will fail to work.
---
src/mesa/drivers/dri/i965/brw_context.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/mesa/drivers/dri/i965/brw_context.c
This is backwards from what we are going to want in the long term, which is:
- brw_vec4.h declares general-purpose vec4 infrastructure needed by
both VS and GS
- brw_vs.h includes brw_vec4.h and adds VS-specific parts.
- brw_gs.h includes brw_vec4.h and adds GS-specific parts.
Note that at the
This patch moves the following things into brw_vec4.{cpp,h}:
- struct brw_vec4_compile
- struct brw_vec4_prog_key
- brw_vec4_prog_data_compare()
- brw_vec4_prog_data_free()
This will allow us to avoid having to include brw_vs.h in
geometry-shader-specific files.
---
Both 3DSTATE_VS and 3DSTATE_GS have a dispatch_grf_start_reg control,
which determines the register where the hardware delivers data sourced
from the URB (push constants followed by per-vertex input data).
For vertex shaders, we always set dispatch_grf_start_reg to 1, since
R1 is always the first
When I initially generaized the vec4_visitor class in preparation for
geometry shaders, I assumed that the setup_attributes() function would
need to be different between vertex and geometry shaders, but its
caller, setup_payload(), could be shared. So I made
setup_attributes() a virtual function.
---
src/mesa/drivers/dri/i965/brw_program.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/src/mesa/drivers/dri/i965/brw_program.c
b/src/mesa/drivers/dri/i965/brw_program.c
index bb9676b..fdb2848 100644
--- a/src/mesa/drivers/dri/i965/brw_program.c
+++
---
src/mesa/drivers/dri/i965/brw_context.h | 3 +++
src/mesa/drivers/dri/i965/brw_state_upload.c | 5 +
2 files changed, 8 insertions(+)
diff --git a/src/mesa/drivers/dri/i965/brw_context.h
b/src/mesa/drivers/dri/i965/brw_context.h
index 0c4aab6..1f1cd0a 100644
---
---
src/mesa/drivers/dri/i965/brw_context.h | 23 +++
1 file changed, 23 insertions(+)
diff --git a/src/mesa/drivers/dri/i965/brw_context.h
b/src/mesa/drivers/dri/i965/brw_context.h
index 1f1cd0a..4e8e239 100644
--- a/src/mesa/drivers/dri/i965/brw_context.h
+++
---
src/mesa/drivers/dri/i965/brw_program.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/src/mesa/drivers/dri/i965/brw_program.c
b/src/mesa/drivers/dri/i965/brw_program.c
index fdb2848..c40d506 100644
--- a/src/mesa/drivers/dri/i965/brw_program.c
+++
---
src/mesa/drivers/dri/i965/brw_defines.h | 9 +
src/mesa/drivers/dri/i965/brw_eu.h | 6 ++
src/mesa/drivers/dri/i965/brw_eu_emit.c | 4 ++--
src/mesa/drivers/dri/i965/brw_shader.cpp| 5 -
src/mesa/drivers/dri/i965/brw_vec4.cpp | 2 ++
---
src/mesa/drivers/dri/i965/brw_defines.h | 16
src/mesa/drivers/dri/i965/brw_shader.cpp| 2 ++
src/mesa/drivers/dri/i965/brw_vec4.h| 3 +++
src/mesa/drivers/dri/i965/brw_vec4_emit.cpp | 18 ++
4 files changed, 39 insertions(+)
diff --git
---
src/mesa/drivers/dri/i965/brw_defines.h | 9 +
src/mesa/drivers/dri/i965/brw_shader.cpp| 2 ++
src/mesa/drivers/dri/i965/brw_vec4.cpp | 1 +
src/mesa/drivers/dri/i965/brw_vec4.h| 1 +
src/mesa/drivers/dri/i965/brw_vec4_emit.cpp | 19 +++
5
---
src/mesa/drivers/dri/i965/brw_defines.h | 10 ++
src/mesa/drivers/dri/i965/brw_shader.cpp| 2 ++
src/mesa/drivers/dri/i965/brw_vec4.h| 2 ++
src/mesa/drivers/dri/i965/brw_vec4_emit.cpp | 31 +
4 files changed, 45 insertions(+)
diff --git
---
src/mesa/drivers/dri/i965/brw_defines.h | 7 +++
src/mesa/drivers/dri/i965/brw_shader.cpp| 2 ++
src/mesa/drivers/dri/i965/brw_vec4.h| 1 +
src/mesa/drivers/dri/i965/brw_vec4_emit.cpp | 18 ++
4 files changed, 28 insertions(+)
diff --git
This patch introduces the vec4_gs_visitor class, which translates
geometry shaders from GLSL IR to back-end opcodes.
This class is derived from vec4_visitor (which is also the base class
for vec4_vs_visitor), so as a result most of the back end code is
shared. The only parts that differ are:
-
This functionality will need to be reused by geometry shaders.
---
src/mesa/drivers/dri/i965/brw_context.h | 6 ++
src/mesa/drivers/dri/i965/brw_vs.c | 24 ++--
2 files changed, 24 insertions(+), 6 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_context.h
We will need access to this array in order to configure the geometry
shader.
---
src/mesa/drivers/dri/i965/brw_context.h | 2 ++
src/mesa/drivers/dri/i965/brw_draw.c| 2 +-
2 files changed, 3 insertions(+), 1 deletion(-)
diff --git a/src/mesa/drivers/dri/i965/brw_context.h
The arguments to brw_urb_WRITE() were getting pretty unwieldy, and we
have to add more flags to support geometry shaders anyhow.
Also plumb these flags through brw_clip_emit_vue(),
brw_set_urb_message(), and the vec4_instruction class.
---
src/mesa/drivers/dri/i965/brw_clip.h | 3 +-
---
src/mesa/drivers/dri/i965/brw_context.h | 9 +
src/mesa/drivers/dri/i965/brw_vs.c | 8 +++-
2 files changed, 16 insertions(+), 1 deletion(-)
diff --git a/src/mesa/drivers/dri/i965/brw_context.h
b/src/mesa/drivers/dri/i965/brw_context.h
index 7c6964f..55d1174 100644
---
---
src/mesa/drivers/dri/i965/brw_context.h | 11 +++
1 file changed, 11 insertions(+)
diff --git a/src/mesa/drivers/dri/i965/brw_context.h
b/src/mesa/drivers/dri/i965/brw_context.h
index 55d1174..4f6c767 100644
--- a/src/mesa/drivers/dri/i965/brw_context.h
+++
From: Eric Anholt e...@anholt.net
All but two of the piglit GLSL 1.50/uniform_buffer tests work, and
maxuniformblocksize and referenced-by-shader work.
v2 (Paul Berry stereotype...@gmail.com): Account for Ken's recent
binding table re-work. Use brw-vec4_gs.bind_bo_offset instead of
---
src/mesa/drivers/dri/i965/Makefile.sources| 1 +
src/mesa/drivers/dri/i965/brw_context.h | 2 +
src/mesa/drivers/dri/i965/brw_defines.h | 10 +
src/mesa/drivers/dri/i965/brw_state.h | 1 +
src/mesa/drivers/dri/i965/brw_state_cache.c | 3 +
Previously, we would always use the same push constant allocation
regardless of what shader programs were being run: the available push
constant space was split into 2 equal size partitions, one for the
vertex shader, and one for the fragment shader.
Now that we are adding geometry shader
Previously, we gave all of the URB space (other than the small amount
that is used for push constants) to the vertex shader. However, when
a geometry shader is active, we need to divide it up between the
vertex and geometry shaders.
The size of the URB entries for the vertex and geometry shaders
The hardware requires that after constant buffers for a stage are
allocated using a 3DSTATE_PUSH_CONSTANT_ALLOC_{VS,HS,DS,GS,PS}
command, and prior to execution of a 3DPRIMITIVE, the corresponding
stage's constant buffers must be reprogrammed using a
3DSTATE_CONSTANT_{VS,HS,DS,GS,PS} command.
---
src/mesa/drivers/dri/i965/brw_context.h | 20 +--
src/mesa/drivers/dri/i965/gen6_vs_state.c | 56 +++
src/mesa/drivers/dri/i965/gen7_vs_state.c | 6 ++--
3 files changed, 56 insertions(+), 26 deletions(-)
diff --git
---
src/mesa/drivers/dri/i965/Makefile.sources | 1 +
src/mesa/drivers/dri/i965/brw_context.h | 2 +
src/mesa/drivers/dri/i965/brw_defines.h | 7 ++
src/mesa/drivers/dri/i965/brw_state.h| 2 +
src/mesa/drivers/dri/i965/brw_state_upload.c | 2 +
On 08/20/2013 07:23 AM, Brian Paul wrote:
---
src/mesa/main/get.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/mesa/main/get.c b/src/mesa/main/get.c
index 09b008a..4f6f59a 100644
--- a/src/mesa/main/get.c
+++ b/src/mesa/main/get.c
@@ -709,7 +709,7 @@
https://bugs.freedesktop.org/show_bug.cgi?id=68296
--- Comment #4 from Kenneth Graunke kenn...@whitecape.org ---
That's Ivybridge (i965).
--
You are receiving this mail because:
You are the assignee for the bug.
___
mesa-dev mailing list
On 08/20/2013 11:30 AM, Paul Berry wrote:
This patch extracts the following logic from
validate_vertex_shader_executable():
(a) Generate an error if the shader writes to both gl_ClipDistance and
gl_ClipVertex.
(b) Record whether the shader writes to gl_ClipDistance in
On 08/20/2013 11:30 AM, Paul Berry wrote:
---
src/mesa/drivers/dri/i965/brw_program.h | 8
src/mesa/drivers/dri/i965/brw_shader.cpp | 2 +-
src/mesa/drivers/dri/i965/brw_shader.h | 7 ++-
src/mesa/drivers/dri/i965/brw_vec4.h | 12 ++--
On 08/20/2013 11:30 AM, Paul Berry wrote:
The arguments to brw_urb_WRITE() were getting pretty unwieldy, and we
have to add more flags to support geometry shaders anyhow.
Also plumb these flags through brw_clip_emit_vue(),
brw_set_urb_message(), and the vec4_instruction class.
---
Series looks good to me.
Jose
- Original Message -
From: Roland Scheidegger srol...@vmware.com
Going to need this soon (not going to bother with avx2 intrinsics at this
time
but don't want to do workarounds for true vector shifts if llvm itself can
use
them just fine and won't
Ken,
I think the big win from using pass-by-pointer is that you can see
what's happening at the call site. References' value syntax and
pointer semantics is a weird mix.
But that might just be the C programmer talking, as you suggested.
-- Chris
___
On 08/20/2013 11:30 AM, Paul Berry wrote:
Previously, we would always use the same push constant allocation
regardless of what shader programs were being run: the available push
constant space was split into 2 equal size partitions, one for the
vertex shader, and one for the fragment shader.
The Gallium implementation is apparently not ready for regular
consumption, so as much as I hate adding more build-time options, here's
another.
Cc: 9.2 mesa-sta...@lists.freedesktop.org
---
configure.ac | 25 +++--
Op 20-08-13 20:14, Matt Turner schreef:
On Tue, Aug 20, 2013 at 8:54 AM, Maarten Lankhorst
maarten.lankho...@canonical.com wrote:
1. There is a new gallium based osmesa, which doesn't work correctly with
wine. My testcase is running opengl32_test from wine/dlls/opengl32/tests.
I've pushed a
On Tue, Aug 20, 2013 at 3:11 PM, Maarten Lankhorst
maarten.lankho...@canonical.com wrote:
if you have multiple *parallel* builds running at the same time you may hit a
bug where one is truncating the files in $(srcdir)/src/mapi/glapi/gen, and
the other one just finished generating them, and
From: Roland Scheidegger srol...@vmware.com
The (complicated!) math is all identical, there's just minimal differences how
sign bit is calculated plus there's an additional subtraction for the argument
going into the polynomial for cos.
The logic stays 100% the same (with a small exception, sign
On Wed, Aug 21, 2013 at 1:12 AM, srol...@vmware.com wrote:
From: Roland Scheidegger srol...@vmware.com
The (complicated!) math is all identical, there's just minimal differences how
sign bit is calculated plus there's an additional subtraction for the argument
going into the polynomial for
Am 21.08.2013 01:28, schrieb Roland Mainz:
On Wed, Aug 21, 2013 at 1:12 AM, srol...@vmware.com wrote:
From: Roland Scheidegger srol...@vmware.com
The (complicated!) math is all identical, there's just minimal differences
how
sign bit is calculated plus there's an additional subtraction for
On Wed, Aug 21, 2013 at 1:45 AM, Roland Scheidegger srol...@vmware.com wrote:
Am 21.08.2013 01:28, schrieb Roland Mainz:
On Wed, Aug 21, 2013 at 1:12 AM, srol...@vmware.com wrote:
From: Roland Scheidegger srol...@vmware.com
[snip]
Can you check whether the new code supports -nan correctly,
60 matches
Mail list logo
