On 03/26/2013 10:51 PM Matt Turner wrote:
On Tue, Mar 26, 2013 at 2:44 PM, Bengt Richter wrote:
uint32_t
component_delta2(uint32_t next, uint32_t prev)
{
return next&0xff00ff)-(prev&0xff00ff)+0x100)&0xff00ff)+
(((next&0xff00)-(prev&0xff00))&0xff00));
}
Does removing all the
This patch consolidates duplicate code in the brw_depthbuffer and
gen7_depthbuffer state atoms. Previously, these state atoms contained
5 chunks of code for emitting the _3DSTATE_DEPTH_BUFFER packet (3 for
Gen4-6 and 2 for Gen7). Also a lot of logic for determining the
appropriate buffer setup wa
Does this patch help?
Marek
On Tue, Mar 26, 2013 at 8:32 AM, Dave Airlie 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 valgrind tra
---
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
--- a/src/gallium/state_track
We weren't correctly propagating the samplers and sampler views
when they were related to geometry shaders.
Signed-off-by: Zack Rusin
---
src/gallium/auxiliary/draw/draw_context.c |4 +-
src/gallium/auxiliary/draw/draw_llvm.c | 83 ---
src/gallium/auxiliary/draw/
Signed-off-by: Zack Rusin
---
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
--- a/src/gallium/auxiliary/draw
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
---
src/gallium/auxiliary/draw/draw_gs.c |3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --gi
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
On Tue, Mar 26, 2013 at 6:45 PM, Dave Airlie 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 27 Mar 2013 08:45, "Dave Airlie" 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
>
>
>>> 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.
>>
>>
I've been hitting several brick walls working on the Haiku GL stuff.
(mostly due to things being too complex for the time I have available)
Given all the recent publicity for Wayland, I decided to look into the
wl_shm stuff. From my point of view wl_shm looks *extremely* simple.
Does anyone
On Tue, Mar 26, 2013 at 2:44 PM, Bengt Richter wrote:
> uint32_t
> component_delta2(uint32_t next, uint32_t prev)
> {
> return next&0xff00ff)-(prev&0xff00ff)+0x100)&0xff00ff)+
> (((next&0xff00)-(prev&0xff00))&0xff00));
> }
Does removing all the spaces make it faster? ;)
__
Am 26.03.2013 20:28, schrieb Marek Olšák:
On Tue, Mar 26, 2013 at 6:44 PM, Christian König
wrote:
Am 26.03.2013 18:02, schrieb Jerome Glisse:
On Tue, Mar 26, 2013 at 12:40 PM, Marek Olšák wrote:
On Tue, Mar 26, 2013 at 3:59 PM, Christian König
wrote:
Am 26.03.2013 15:34, schrieb Marek Olš
I think this should be fixed in drivers.
Marek
On Tue, Mar 26, 2013 at 7:38 PM, Ondrej Holecek 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 wrote:
>> >> On Saturday 23 of Mar
On Tue, Mar 26, 2013 at 6:44 PM, Christian König
wrote:
> Am 26.03.2013 18:02, schrieb Jerome Glisse:
>
>> On Tue, Mar 26, 2013 at 12:40 PM, Marek Olšák wrote:
>>>
>>> On Tue, Mar 26, 2013 at 3:59 PM, Christian König
>>> wrote:
Am 26.03.2013 15:34, schrieb Marek Olšák:
> Speak
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 wrote:
> >> On Saturday 23 of March 2013 00:50:59 Marek Olšák wrote:
>
> >
> >> The third issue is that on both 32bit and 64bit build fon
On Tue, Mar 26, 2013 at 1:39 AM, violin yanev 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:
> EGL_MESA_drm_im
On Tue, Mar 26, 2013 at 2:14 PM, Jordan Justen wrote:
> On Tue, Mar 26, 2013 at 10:34 AM, Jerome Glisse wrote:
>> On Tue, Mar 26, 2013 at 4:39 AM, violin yanev wrote:
>>> Thanks for your replies guys!
>>>
>>> The output of eglinfo is:
>>> EGL API version: 1.4
>>> EGL vendor string: Mesa Project
On Tue, Mar 26, 2013 at 10:34 AM, Jerome Glisse wrote:
> On Tue, Mar 26, 2013 at 4:39 AM, violin yanev 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 Op
Am 26.03.2013 18:02, schrieb Jerome Glisse:
On Tue, Mar 26, 2013 at 12:40 PM, Marek Olšák wrote:
On Tue, Mar 26, 2013 at 3:59 PM, Christian König
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 sta
On Tue, Mar 26, 2013 at 4:39 AM, violin yanev 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:
> EGL_MESA_drm_im
(I'm re-sending this message because the attachment was too large for
mesa-dev, and because I want to add wayland-devel CC. The valgrind output
can be found here: http://runeks.dk/files/callgrind.out.11362).
Seems like you are right Pekka.
I just ran weston through valgrind, and got some interest
On Die, 2013-03-26 at 17:37 +0100, Christian König wrote:
> 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
> >>
> >> Signed-off-by: Christian König
> >> [...]
> >> diff --git a/src/gallium/drivers/radeonsi/rade
On Tue, Mar 26, 2013 at 12:40 PM, Marek Olšák wrote:
> On Tue, Mar 26, 2013 at 3:59 PM, Christian König
> 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
>
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
---
src/gallium/auxiliary/draw/draw_gs.c | 54 ++
src/gallium/auxi
To be able to add llvm paths later on we need to have some common
interface for them.
Signed-off-by: Zack Rusin
---
src/gallium/auxiliary/draw/draw_gs.c | 270 ++
src/gallium/auxiliary/draw/draw_gs.h | 14 ++
2 files changed, 156 insertions(+), 128 deletions(-)
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
---
src/gallium/auxiliary/draw/draw_llvm.c| 17 +++--
src/gallium/auxiliary/draw/draw_llvm.h| 15
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 co
On Tue, Mar 26, 2013 at 3:59 PM, Christian König
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 functions), you wa
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
---
src/gallium/auxiliary/gallivm/lp_bld_tgsi.h|6
src/gallium/auxiliary/ga
A few tests were missing this crucial property.
Signed-off-by: Zack Rusin
---
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 +
src/gallium/tests/graw/geomet
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
Signed-off-by: Christian König
[...]
diff --git a/src/gallium/drivers/radeonsi/radeonsi_shader.h
b/src/gallium/drivers/radeonsi/radeonsi_shader.h
index 9dae742..e09f297
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 th
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 by
Patches 1-3 are
Reviewed-by: Michel Dänzer
Tested-by: Michel Dänzer
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast | Debian, X and DRI developer
___
mesa-dev mailing list
mesa-
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 f
On Die, 2013-03-26 at 14:51 +0100, Christian König wrote:
> From: Christian König
>
> Signed-off-by: Christian König
> [...]
> diff --git a/src/gallium/drivers/radeonsi/radeonsi_shader.h
> b/src/gallium/drivers/radeonsi/radeonsi_shader.h
> index 9dae742..e09f297 100644
> --- a/src/gallium/driv
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 use
Am 26.03.2013 14:42, schrieb Jerome Glisse:
On Tue, Mar 26, 2013 at 6:22 AM, Christian König
wrote:
Am 25.03.2013 18:15, schrieb j.gli...@gmail.com:
From: Jerome Glisse
Same as on r600, trace cs execution by writting cs offset after each
states, this allow to pin point lockup inside command
From: Christian König
Signed-off-by: Christian König
---
src/gallium/drivers/radeonsi/radeonsi_shader.c | 66 +++-
src/gallium/drivers/radeonsi/radeonsi_shader.h | 23 +
src/gallium/drivers/radeonsi/si_state.c| 32 +++-
src/gallium/drivers/radeo
From: Christian König
This works different than on R600, we need to add the start instance manually.
Signed-off-by: Christian König
---
src/gallium/drivers/radeonsi/radeonsi_shader.c | 13 -
src/gallium/drivers/radeonsi/radeonsi_shader.h | 12 +++-
src/gallium/drivers/r
From: Christian König
This should be used by both SI and R600.
Signed-off-by: Christian König
---
src/gallium/drivers/r600/r600_llvm.c | 12
.../drivers/radeon/radeon_setup_tgsi_llvm.c| 12
2 files changed, 12 insertions(+), 12 deletions(-)
From: Christian König
Signed-off-by: Christian König
---
src/gallium/drivers/radeonsi/radeonsi_pipe.c |2 +-
src/gallium/drivers/radeonsi/radeonsi_shader.c | 35 ++--
src/gallium/drivers/radeonsi/radeonsi_shader.h |6 +++-
src/gallium/drivers/radeonsi/si_state_dr
Signed-off-by: Erik Faye-Lund
---
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 e081cbf..dc308e5 100644
--
On Tue, Mar 26, 2013 at 6:22 AM, Christian König
wrote:
> Am 25.03.2013 18:15, schrieb j.gli...@gmail.com:
>
>> From: Jerome Glisse
>>
>> 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 sco
Am 26.03.2013 12:53, schrieb Michel Dänzer:
On Die, 2013-03-26 at 11:56 +0100, Christian König wrote:
From: Christian König
The include isn't needed and the file has moved with LLVM master.
Signed-off-by: Christian König
Reviewed-by: Michel Dänzer
The rest of the series seems unchanged, s
On Die, 2013-03-26 at 11:56 +0100, Christian König wrote:
> From: Christian König
>
> The include isn't needed and the file has moved with LLVM master.
>
> Signed-off-by: Christian König
Reviewed-by: Michel Dänzer
The rest of the series seems unchanged, so my review of it stands.
--
Eart
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
>> 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,
>>>
>>>
On 03/26/2013 02:00 AM, Marek Olšák wrote:
On Mon, Mar 25, 2013 at 10:38 PM, Ondrej Holecek 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, they do not appl
From: Christian König
Signed-off-by: Christian König
---
src/gallium/drivers/radeonsi/radeonsi_shader.c | 57 +++-
1 file changed, 45 insertions(+), 12 deletions(-)
diff --git a/src/gallium/drivers/radeonsi/radeonsi_shader.c
b/src/gallium/drivers/radeonsi/radeonsi_shader
From: Christian König
Signed-off-by: Christian König
---
src/gallium/drivers/radeonsi/radeonsi_shader.c | 67 ++--
1 file changed, 51 insertions(+), 16 deletions(-)
diff --git a/src/gallium/drivers/radeonsi/radeonsi_shader.c
b/src/gallium/drivers/radeonsi/radeonsi_shader
From: Christian König
The include isn't needed and the file has moved with LLVM master.
Signed-off-by: Christian König
---
src/gallium/drivers/radeon/radeon_llvm_emit.cpp |1 -
1 file changed, 1 deletion(-)
diff --git a/src/gallium/drivers/radeon/radeon_llvm_emit.cpp
b/src/gallium/driver
From: Christian König
Signed-off-by: Christian König
---
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
b/src/gallium/drivers/radeonsi/radeonsi_shader.c
inde
From: Christian König
Signed-off-by: Christian König
---
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
b/src/gallium/drivers/radeonsi/radeonsi_shader.
From: Christian König
Now the backend handles that itself.
Signed-off-by: Christian König
---
src/gallium/drivers/radeonsi/radeonsi_shader.c |9 -
1 file changed, 9 deletions(-)
diff --git a/src/gallium/drivers/radeonsi/radeonsi_shader.c
b/src/gallium/drivers/radeonsi/radeonsi_sh
Am 25.03.2013 18:15, schrieb j.gli...@gmail.com:
From: Jerome Glisse
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 instead of WRITE_M
Hi Brian,
On 3/26/13, Brian Paul 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 set num_t
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
EGL_KHR_image_pi
https://bugs.freedesktop.org/show_bug.cgi?id=3485
--- Comment #11 from chemtech ---
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 for the bug.
On Tue, 26 Mar 2013 03:30:58 +0100
Rune Kjær Svendsen 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
> changed for every f
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, wit
63 matches
Mail list logo
