so I've been playing with MSAA in softpipe and saw this, I don't think
any of my code is causing it, but it does take an MSAA test to trigger
it
with texelFetch fs sampler2DMS 4 I get the below valgrind trace
so it looks like we are keeping a reference in ctx-Array._DrawArrays
that is stale,
On Tue, 26 Mar 2013 03:30:58 +0100
Rune Kjær Svendsen runesv...@gmail.com wrote:
Marek, do you have an idea on where the currency bottleneck is?
I just did a profiling with sysprof, zooming in on the desktop in Weston
and moving the mouse wildly around, so that the buffer is completely
https://bugs.freedesktop.org/show_bug.cgi?id=3485
--- Comment #11 from chemtech patsev.an...@gmail.com ---
Daniel Stone,
Do you still experience this issue with newer soft ?
Please check the status of your issue.
Or close this bug.
--
You are receiving this mail because:
You are the assignee
Thanks for your replies guys!
The output of eglinfo is:
EGL API version: 1.4
EGL vendor string: Mesa Project
EGL version string: 1.4 (DRI2)
EGL client APIs: OpenGL OpenGL_ES OpenGL_ES2
EGL extensions string:
EGL_MESA_drm_image EGL_WL_bind_wayland_display EGL_KHR_image_base
Hi Brian,
On 3/26/13, Brian Paul bri...@vmware.com wrote:
I guess to define LP_NUM_THREADS as an environment variable, correct?
Yes.
I've tried to define LP_NUM_THREADS=10, but does not work.
The limit is currently 8. If your VM only has one CPU core, then
llvmpipe will automatically
Am 25.03.2013 18:15, schrieb j.gli...@gmail.com:
From: Jerome Glisse jgli...@redhat.com
Same as on r600, trace cs execution by writting cs offset after each
states, this allow to pin point lockup inside command stream and
narrow down the scope of lockup investigation.
v2: Use WRITE_DATA packet
From: Christian König christian.koe...@amd.com
Now the backend handles that itself.
Signed-off-by: Christian König christian.koe...@amd.com
---
src/gallium/drivers/radeonsi/radeonsi_shader.c |9 -
1 file changed, 9 deletions(-)
diff --git
From: Christian König christian.koe...@amd.com
Signed-off-by: Christian König christian.koe...@amd.com
---
src/gallium/drivers/radeonsi/radeonsi_shader.c | 32 ++--
1 file changed, 25 insertions(+), 7 deletions(-)
diff --git a/src/gallium/drivers/radeonsi/radeonsi_shader.c
From: Christian König christian.koe...@amd.com
Signed-off-by: Christian König christian.koe...@amd.com
---
src/gallium/drivers/radeonsi/radeonsi_shader.c | 18 ++
1 file changed, 10 insertions(+), 8 deletions(-)
diff --git a/src/gallium/drivers/radeonsi/radeonsi_shader.c
From: Christian König christian.koe...@amd.com
The include isn't needed and the file has moved with LLVM master.
Signed-off-by: Christian König christian.koe...@amd.com
---
src/gallium/drivers/radeon/radeon_llvm_emit.cpp |1 -
1 file changed, 1 deletion(-)
diff --git
From: Christian König christian.koe...@amd.com
Signed-off-by: Christian König christian.koe...@amd.com
---
src/gallium/drivers/radeonsi/radeonsi_shader.c | 67 ++--
1 file changed, 51 insertions(+), 16 deletions(-)
diff --git
From: Christian König christian.koe...@amd.com
Signed-off-by: Christian König christian.koe...@amd.com
---
src/gallium/drivers/radeonsi/radeonsi_shader.c | 57 +++-
1 file changed, 45 insertions(+), 12 deletions(-)
diff --git
On 03/26/2013 02:00 AM, Marek Olšák wrote:
On Mon, Mar 25, 2013 at 10:38 PM, Ondrej Holecek aaa...@gmail.com wrote:
On Saturday 23 of March 2013 00:50:59 Marek Olšák wrote:
Hi everyone, one image is better than a thousand words:
...
Hi,
I tried your patches and hit a few problems. As first,
On 26.03.2013 12:18, Vadim Girlin wrote:
On 03/26/2013 02:00 AM, Marek Olšák wrote:
On Mon, Mar 25, 2013 at 10:38 PM, Ondrej Holecek aaa...@gmail.com
wrote:
On Saturday 23 of March 2013 00:50:59 Marek Olšák wrote:
Hi everyone, one image is better than a thousand words:
...
Hi,
I tried
On Die, 2013-03-26 at 11:56 +0100, Christian König wrote:
From: Christian König christian.koe...@amd.com
The include isn't needed and the file has moved with LLVM master.
Signed-off-by: Christian König christian.koe...@amd.com
Reviewed-by: Michel Dänzer michel.daen...@amd.com
The rest of
Signed-off-by: Erik Faye-Lund kusmab...@gmail.com
---
Here you go, a version of the patch prepared for git-am
src/gallium/docs/source/debugging.rst | 4
1 file changed, 4 insertions(+)
diff --git a/src/gallium/docs/source/debugging.rst
b/src/gallium/docs/source/debugging.rst
index
From: Christian König christian.koe...@amd.com
Signed-off-by: Christian König christian.koe...@amd.com
---
src/gallium/drivers/radeonsi/radeonsi_pipe.c |2 +-
src/gallium/drivers/radeonsi/radeonsi_shader.c | 35 ++--
src/gallium/drivers/radeonsi/radeonsi_shader.h |
From: Christian König christian.koe...@amd.com
This works different than on R600, we need to add the start instance manually.
Signed-off-by: Christian König christian.koe...@amd.com
---
src/gallium/drivers/radeonsi/radeonsi_shader.c | 13 -
From: Christian König christian.koe...@amd.com
Signed-off-by: Christian König christian.koe...@amd.com
---
src/gallium/drivers/radeonsi/radeonsi_shader.c | 66 +++-
src/gallium/drivers/radeonsi/radeonsi_shader.h | 23 +
src/gallium/drivers/radeonsi/si_state.c
Am 26.03.2013 14:42, schrieb Jerome Glisse:
On Tue, Mar 26, 2013 at 6:22 AM, Christian König
deathsim...@vodafone.de wrote:
Am 25.03.2013 18:15, schrieb j.gli...@gmail.com:
From: Jerome Glisse jgli...@redhat.com
Same as on r600, trace cs execution by writting cs offset after each
states,
Speaking of si_pm4_state, I think it's a horrible mechanism for
anything other than constant state objects (create/bind/delete
functions). For everything else (set/draw functions), you want to emit
directly into the command stream. It's not so different from the bad
state management which r600g
On Die, 2013-03-26 at 14:51 +0100, Christian König wrote:
From: Christian König christian.koe...@amd.com
Signed-off-by: Christian König christian.koe...@amd.com
[...]
diff --git a/src/gallium/drivers/radeonsi/radeonsi_shader.h
b/src/gallium/drivers/radeonsi/radeonsi_shader.h
index
Am 26.03.2013 15:34, schrieb Marek Olšák:
Speaking of si_pm4_state, I think it's a horrible mechanism for
anything other than constant state objects (create/bind/delete
functions). For everything else (set/draw functions), you want to emit
directly into the command stream. It's not so different
Patches 1-3 are
Reviewed-by: Michel Dänzer michel.daen...@amd.com
Tested-by: Michel Dänzer michel.daen...@amd.com
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast | Debian, X and DRI developer
Hello,
I've noticed the GLX_LARGEST_PBUFFER property is not implemented correctly
(it is, but only in Gallium). Specification:
http://www.opengl.org/sdk/docs/man2/xhtml/glXCreatePbuffer.xml
The value should be used to decrease buffer size when necessary, but also
stored so it can be retrieved
On 03/25/2013 03:48 AM, Chris Forbes wrote:
Fixes various test fallout from 90b5a2425a on Pineview, which claims to
support ARB_internalformat_query but doesn't actually provide the
driverfunc.
That driver is still broken [GetInternalformativ will still segfault!]
but it was silly to be going
Am 26.03.2013 15:56, schrieb Michel Dänzer:
On Die, 2013-03-26 at 14:51 +0100, Christian König wrote:
From: Christian König christian.koe...@amd.com
Signed-off-by: Christian König christian.koe...@amd.com
[...]
diff --git a/src/gallium/drivers/radeonsi/radeonsi_shader.h
A few tests were missing this crucial property.
Signed-off-by: Zack Rusin za...@vmware.com
---
src/gallium/tests/graw/geometry-shader/add-mix.txt |1 +
src/gallium/tests/graw/geometry-shader/add.txt |1 +
src/gallium/tests/graw/geometry-shader/mov-cb-2d.txt |1 +
we were missing implementation of the breakc instruction and our
TGSI semantics currently require an implicit endprim at the end
of GS if none is present - this implements both.
Signed-off-by: Zack Rusin za...@vmware.com
---
src/gallium/auxiliary/gallivm/lp_bld_tgsi.h|6
On Tue, Mar 26, 2013 at 3:59 PM, Christian König
deathsim...@vodafone.de wrote:
Am 26.03.2013 15:34, schrieb Marek Olšák:
Speaking of si_pm4_state, I think it's a horrible mechanism for
anything other than constant state objects (create/bind/delete
functions). For everything else (set/draw
This set implements code generation of geometry shaders in
the LLVM paths. There are some cleanups that will follow
(e.g. changing the input array to handle lp_native vectors
and not TGSI_NUM_CHANNELS) but all the simple examples
are working and as far as I can tell there's no regressions
in the
The member was never used and we'll need to handle it differently
because gs will also need samplers/textures setup.
Signed-off-by: Zack Rusin za...@vmware.com
---
src/gallium/auxiliary/draw/draw_llvm.c| 17 +++--
src/gallium/auxiliary/draw/draw_llvm.h
To be able to add llvm paths later on we need to have some common
interface for them.
Signed-off-by: Zack Rusin za...@vmware.com
---
src/gallium/auxiliary/draw/draw_gs.c | 270 ++
src/gallium/auxiliary/draw/draw_gs.h | 14 ++
2 files changed, 156 insertions(+),
Allows executing gs on up to 4 primitives at a time. Will also be
required by the llvm code because there we definitely don't want
to flush with just a single primitive.
Signed-off-by: Zack Rusin za...@vmware.com
---
src/gallium/auxiliary/draw/draw_gs.c | 54 ++
On Tue, Mar 26, 2013 at 12:40 PM, Marek Olšák mar...@gmail.com wrote:
On Tue, Mar 26, 2013 at 3:59 PM, Christian König
deathsim...@vodafone.de wrote:
Am 26.03.2013 15:34, schrieb Marek Olšák:
Speaking of si_pm4_state, I think it's a horrible mechanism for
anything other than constant state
On Tue, Mar 26, 2013 at 4:39 AM, violin yanev violin.ya...@gmail.com wrote:
Thanks for your replies guys!
The output of eglinfo is:
EGL API version: 1.4
EGL vendor string: Mesa Project
EGL version string: 1.4 (DRI2)
EGL client APIs: OpenGL OpenGL_ES OpenGL_ES2
EGL extensions string:
On Tue, Mar 26, 2013 at 10:34 AM, Jerome Glisse j.gli...@gmail.com wrote:
On Tue, Mar 26, 2013 at 4:39 AM, violin yanev violin.ya...@gmail.com wrote:
Thanks for your replies guys!
The output of eglinfo is:
EGL API version: 1.4
EGL vendor string: Mesa Project
EGL version string: 1.4 (DRI2)
On Tue, Mar 26, 2013 at 2:14 PM, Jordan Justen jljus...@gmail.com wrote:
On Tue, Mar 26, 2013 at 10:34 AM, Jerome Glisse j.gli...@gmail.com wrote:
On Tue, Mar 26, 2013 at 4:39 AM, violin yanev violin.ya...@gmail.com wrote:
Thanks for your replies guys!
The output of eglinfo is:
EGL API
On Tue, Mar 26, 2013 at 1:39 AM, violin yanev violin.ya...@gmail.com wrote:
Thanks for your replies guys!
The output of eglinfo is:
EGL API version: 1.4
EGL vendor string: Mesa Project
EGL version string: 1.4 (DRI2)
EGL client APIs: OpenGL OpenGL_ES OpenGL_ES2
EGL extensions string:
On Tuesday 26 of March 2013 15:18:06 Vadim Girlin wrote:
On 03/26/2013 02:00 AM, Marek Olšák wrote:
On Mon, Mar 25, 2013 at 10:38 PM, Ondrej Holecek aaa...@gmail.com wrote:
On Saturday 23 of March 2013 00:50:59 Marek Olšák wrote:
The third issue is that on both 32bit and 64bit
On Tue, Mar 26, 2013 at 6:44 PM, Christian König
deathsim...@vodafone.de wrote:
Am 26.03.2013 18:02, schrieb Jerome Glisse:
On Tue, Mar 26, 2013 at 12:40 PM, Marek Olšák mar...@gmail.com wrote:
On Tue, Mar 26, 2013 at 3:59 PM, Christian König
deathsim...@vodafone.de wrote:
Am 26.03.2013
I think this should be fixed in drivers.
Marek
On Tue, Mar 26, 2013 at 7:38 PM, Ondrej Holecek aaa...@gmail.com wrote:
On Tuesday 26 of March 2013 15:18:06 Vadim Girlin wrote:
On 03/26/2013 02:00 AM, Marek Olšák wrote:
On Mon, Mar 25, 2013 at 10:38 PM, Ondrej Holecek aaa...@gmail.com wrote:
Am 26.03.2013 20:28, schrieb Marek Olšák:
On Tue, Mar 26, 2013 at 6:44 PM, Christian König
deathsim...@vodafone.de wrote:
Am 26.03.2013 18:02, schrieb Jerome Glisse:
On Tue, Mar 26, 2013 at 12:40 PM, Marek Olšák mar...@gmail.com wrote:
On Tue, Mar 26, 2013 at 3:59 PM, Christian König
On Tue, Mar 26, 2013 at 2:44 PM, Bengt Richter b...@oz.net wrote:
uint32_t
component_delta2(uint32_t next, uint32_t prev)
{
return next0xff00ff)-(prev0xff00ff)+0x100)0xff00ff)+
(((next0xff00)-(prev0xff00))0xff00));
}
Does removing all the spaces make it faster? ;)
correctly). But Marek is quite right that this only counts for state
objects
and makes no sense for set_* and draw_* calls (and I'm currently thinking
how to avoid that and can't come up with a proper solution). Anyway it's
definitely not an urgent problem for radeonsi.
It will be a
On 27 Mar 2013 08:45, Dave Airlie airl...@gmail.com wrote:
correctly). But Marek is quite right that this only counts for state
objects
and makes no sense for set_* and draw_* calls (and I'm currently thinking
how to avoid that and can't come up with a proper solution). Anyway it's
I recommend using OpenMP for this kind of pixel processing,
specifically the parallel for. It's pretty easy to use and you could
do wonders with it, i.e. taking advantage of all CPU cores on *any*
system. You could also offload the whole thing to another thread and
continue there.
Marek
On Tue,
On Tue, Mar 26, 2013 at 6:45 PM, Dave Airlie airl...@gmail.com wrote:
correctly). But Marek is quite right that this only counts for state
objects
and makes no sense for set_* and draw_* calls (and I'm currently thinking
how to avoid that and can't come up with a proper solution). Anyway it's
A few cleanups, plus fixes for texture sampling for the llvm
geometry shaders. This is on top of the previous patchset.
Zack Rusin (3):
draw: Allocate the output buffer for output primitives
draw/llvm: Cleanup the store debugging code
llvmpipe/draw: Fix texture sampling in geometry shaders
We were allocating the output buffer but using the input
primitives. We need to allocate that buffer using the
maximum number of output, not input, primitives.
Signed-off-by: Zack Rusin za...@vmware.com
---
src/gallium/auxiliary/draw/draw_gs.c |3 +--
1 file changed, 1 insertion(+), 2
Signed-off-by: Zack Rusin za...@vmware.com
---
src/gallium/auxiliary/draw/draw_llvm.c | 13 +
1 file changed, 5 insertions(+), 8 deletions(-)
diff --git a/src/gallium/auxiliary/draw/draw_llvm.c
b/src/gallium/auxiliary/draw/draw_llvm.c
index 1b0b1b9..f857183 100644
---
We weren't correctly propagating the samplers and sampler views
when they were related to geometry shaders.
Signed-off-by: Zack Rusin za...@vmware.com
---
src/gallium/auxiliary/draw/draw_context.c |4 +-
src/gallium/auxiliary/draw/draw_llvm.c | 83 ---
---
src/gallium/state_trackers/dri/common/dri_drawable.c |3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/src/gallium/state_trackers/dri/common/dri_drawable.c
b/src/gallium/state_trackers/dri/common/dri_drawable.c
index 00ae1da..cd4a36a 100644
---
Does this patch help?
Marek
On Tue, Mar 26, 2013 at 8:32 AM, Dave Airlie airl...@gmail.com wrote:
so I've been playing with MSAA in softpipe and saw this, I don't think
any of my code is causing it, but it does take an MSAA test to trigger
it
with texelFetch fs sampler2DMS 4 I get the below
54 matches
Mail list logo
