module.
Small typo "gellium" instead of "gallium".
Signed-off-by: Emil Velikov
The dependency to x11-xcb and xcb-dri2 doesn't pull in core xcb as well?
Anyway patch looks good to me and is Reviewed-by: Christian König
Regards,
Christian.
---
configure
adeon: Pass GART page flags to
[PATCH 3/5] drm/radeon: Allow write-combined CPU mappings of BOs in
[PATCH 4/5] drm/radeon: Use write-combined CPU mappings of rings and
Those four are Reviewed-by: Christian König
[PATCH 5/5] drm/radeon: Use VRAM for indirect buffers on >= SI
I'm still
Am 18.07.2014 05:07, schrieb Michel Dänzer:
[PATCH 5/5] drm/radeon: Use VRAM for indirect buffers on >= SI
I'm still not very keen with this change since I still don't understand
the reason why it's faster than with GTT. Definitely needs more testing
on a wider range of systems.
Sure. If anyone
Am 19.07.2014 03:15, schrieb Michel Dänzer:
On 19.07.2014 00:47, Christian König wrote:
Am 18.07.2014 05:07, schrieb Michel Dänzer:
[PATCH 5/5] drm/radeon: Use VRAM for indirect buffers on >= SI
I'm still not very keen with this change since I still don't understand
the reason wh
Am 23.07.2014 05:54, schrieb Michel Dänzer:
On 21.07.2014 17:07, Christian König wrote:
Am 19.07.2014 03:15, schrieb Michel Dänzer:
On 19.07.2014 00:47, Christian König wrote:
Am 18.07.2014 05:07, schrieb Michel Dänzer:
[PATCH 5/5] drm/radeon: Use VRAM for indirect buffers on >= SI
Am 23.07.2014 09:21, schrieb Michel Dänzer:
On 23.07.2014 15:42, Christian König wrote:
Am 23.07.2014 05:54, schrieb Michel Dänzer:
On 21.07.2014 17:07, Christian König wrote:
Am 19.07.2014 03:15, schrieb Michel Dänzer:
On 19.07.2014 00:47, Christian König wrote:
Am 18.07.2014 05:07
Am 31.07.2014 um 11:43 schrieb Michel Dänzer:
From: Michel Dänzer
Signed-off-by: Michel Dänzer
At least for PIPE_USAGE_STREAM buffers that's a bad idea, cause they are
used by VDPAU to read back to data to a CPU buffer and that's really
slow from VRAM.
Christian.
---
src/gallium/driv
Am 31.07.2014 um 11:57 schrieb Michel Dänzer:
On 31.07.2014 18:52, Christian König wrote:
Am 31.07.2014 um 11:43 schrieb Michel Dänzer:
From: Michel Dänzer
Signed-off-by: Michel Dänzer
At least for PIPE_USAGE_STREAM buffers that's a bad idea, cause they are
used by VDPAU to read ba
Am 19.07.2013 22:18, schrieb Tom Stellard:
From: Tom Stellard
Both patches are: Reviewed-by: Christian König
---
src/gallium/drivers/radeonsi/radeonsi_shader.c | 29 ++
1 file changed, 20 insertions(+), 9 deletions(-)
diff --git a/src/gallium/drivers/radeonsi
a
further issue with final displaying, it only works sometimes,
but this patch is at least necessary to help debug further.
Signed-off-by: Dave Airlie
Looks good to me.
Reviewed-by: Christian König
---
src/gallium/auxiliary/vl/vl_winsys_dri.c | 20 +++-
1 file changed, 19
Am 06.08.2013 10:53, schrieb Michel Dänzer:
From: Michel Dänzer
Fixes spurious 'Assertion `num_sgprs <= 104' failed.' with shaders using
all 104 SGPRs.
Cc: mesa-sta...@lists.freedesktop.org
Signed-off-by: Michel Dänzer
Reviewed-by: Christian König
---
src/galliu
Am 08.08.2013 02:20, schrieb Marek Olšák:
FMASK is bound as a separate texture. For every texture, there can be
an FMASK. Therefore a separate array of resource slots has to be added.
This adds a new mechanism for emitting resource descriptors, its features are:
- resource descriptors are stored
Am 08.08.2013 02:20, schrieb Marek Olšák:
This started as an attempt to add support for MSAA texture transfers and
MSAA depth-stencil decompression for the DB->CB copy path.
It has gotten a bit out of control, but it's for the greater good.
Some changes do not make much sense, they are there jus
Am 08.08.2013 02:20, schrieb Marek Olšák:
It's the same as in r600g. Look how simple it is.
That concept has the problem that we don't necessary know in which order
the state is emitted.
Why not just add an "emit" callback to si_pm4_state for the short term
instead?
For the long term we s
Am 08.08.2013 10:30, schrieb Michel Dänzer:
On Don, 2013-08-08 at 02:20 +0200, Marek Olšák wrote:
diff --git a/src/gallium/drivers/radeonsi/si_state_draw.c
b/src/gallium/drivers/radeonsi/si_state_draw.c
index 746ace6..4208fa7 100644
--- a/src/gallium/drivers/radeonsi/si_state_draw.c
+++ b/src/g
ow you the documents on that).
Anyway, the order is determined by the order of si_add_atom calls,
which should be done once in create_context.
Then why don't you just use a constant structure for this?
Christian.
Marek
On Thu, Aug 8, 2013 at 10:32 AM, Christian König
wrote:
Am 0
Am 08.08.2013 14:38, schrieb Marek Olšák:
.On Thu, Aug 8, 2013 at 9:47 AM, Christian König
wrote:
Am 08.08.2013 02:20, schrieb Marek Olšák:
FMASK is bound as a separate texture. For every texture, there can be
an FMASK. Therefore a separate array of resource slots has to be added.
This adds
Am 08.08.2013 16:33, schrieb Marek Olšák:
On Thu, Aug 8, 2013 at 3:09 PM, Christian König wrote:
Am 08.08.2013 14:38, schrieb Marek Olšák:
.On Thu, Aug 8, 2013 at 9:47 AM, Christian König
wrote:
Am 08.08.2013 02:20, schrieb Marek Olšák:
FMASK is bound as a separate texture. For every
=65958
Signed-off-by: Alex Deucher
CC: "9.2"
CC: "9.1"
Sounds like a good idea to me.
Reviewed-by: Christian König
---
src/gallium/winsys/radeon/drm/radeon_drm_winsys.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/gallium/winsys/radeon/drm/ra
Am 08.08.2013 21:38, schrieb Alex Deucher:
On Thu, Aug 8, 2013 at 1:34 PM, Marek Olšák wrote:
On Thu, Aug 8, 2013 at 6:57 PM, Christian König wrote:
Am 08.08.2013 16:33, schrieb Marek Olšák:
On Thu, Aug 8, 2013 at 3:09 PM, Christian König
wrote:
Am 08.08.2013 14:38, schrieb Marek Olšák
Am 09.08.2013 15:29, schrieb Marek Olšák:
On Fri, Aug 9, 2013 at 10:34 AM, Christian König
wrote:
Am 08.08.2013 21:38, schrieb Alex Deucher:
On Thu, Aug 8, 2013 at 1:34 PM, Marek Olšák wrote:
On Thu, Aug 8, 2013 at 6:57 PM, Christian König
wrote:
Am 08.08.2013 16:33, schrieb Marek Olšák
Am 09.08.2013 20:06, schrieb Marek Olšák:
[SNIP]
What if I kept the current emission code, and only allocated a new
buffer at the end of the emit function, copied all descriptors to it
using CP_DMA or COPY_DATA, and pointed SPI_SHADER_USER_DATA to it. The
buffer where the descriptors are updated
ext), so I
strongly think we should be on the save side with 16 slots here. I'm
just not sure if the SQ could add some more depth to our pipeline, maybe
Alex knows more on this.
Christian.
Marek
On Sat, Aug 10, 2013 at 10:45 AM, Christian König
wrote:
Am 09.08.2013 20:06, schrieb Marek Olšák
Am 14.08.2013 08:13, schrieb Rico Schüller:
Hi,
this patch adds the level query support to the video decoders. This
uses some more reasonable defaults.
This improves the situation in bug 67530 .
The patch is:
Reviewed-by: Christian König
I assume you don't have commit access,
Am 14.08.2013 13:04, schrieb Rico Schüller:
On 14.08.2013 12:47, Christian König wrote:
Am 14.08.2013 08:13, schrieb Rico Schüller:
Hi,
this patch adds the level query support to the video decoders. This
uses some more reasonable defaults.
This improves the situation in bug 67530 .
The
Am 15.08.2013 09:33, schrieb Michel Dänzer:
On Don, 2013-08-15 at 05:25 +0200, Marek Olšák wrote:
(This should be applied before MSAA, which will need to be rebased.)
It moves all sampler view descriptors to a buffer.
It supports partial resource updates and it can also unbind resources
(requir
Am 15.08.2013 05:25, schrieb Marek Olšák:
(This should be applied before MSAA, which will need to be rebased.)
It moves all sampler view descriptors to a buffer.
It supports partial resource updates and it can also unbind resources
(required for FMASK texturing).
The buffer contains all sampler
Am 15.08.2013 12:54, schrieb Marek Olšák:
On Thu, Aug 15, 2013 at 10:27 AM, Christian König
wrote:
Am 15.08.2013 05:25, schrieb Marek Olšák:
(This should be applied before MSAA, which will need to be rebased.)
It moves all sampler view descriptors to a buffer.
It supports partial resource
Am 15.08.2013 19:01, schrieb Marek Olšák:
(This should be applied before MSAA, which will need to be rebased.)
It moves all sampler view descriptors to a buffer.
It supports partial resource updates and it can also unbind resources
(required for FMASK texturing).
The buffer contains all sampler
Am 15.08.2013 14:54, schrieb Emil Velikov:
On 15/08/13 13:41, Rico Schüller wrote:
On 15.08.2013 02:10, Emil Velikov wrote:
Fix a typo introduced with commit d1ba1055d9 -
vl: Add support for max level query v2
Cc: Rico Schüller
Cc: Christian König
Bugzilla: https://bugs.freedesktop.org
From: Christian König
Signed-off-by: Christian König
---
src/gallium/auxiliary/util/u_video.h | 12 +++
src/gallium/auxiliary/vl/vl_decoder.c |4 +--
src/gallium/auxiliary/vl/vl_mpeg12_bitstream.c |2 +-
src/gallium/auxiliary/vl/vl_mpeg12_decoder.c
From: Christian König
Signed-off-by: Christian König
---
src/gallium/auxiliary/vl/vl_decoder.c |4 +++-
src/gallium/auxiliary/vl/vl_decoder.h |3 ++-
src/gallium/auxiliary/vl/vl_video_buffer.c |1 +
src/gallium/drivers/ilo/ilo_screen.c|3
From: Christian König
Signed-off-by: Christian König
---
src/gallium/auxiliary/vl/vl_video_buffer.c |3 ++-
src/gallium/auxiliary/vl/vl_video_buffer.h |3 ++-
src/gallium/drivers/ilo/ilo_format.c|5 +++--
src/gallium/drivers/nouveau/nouveau_vp3_video.c |5
Am 16.08.2013 22:41, schrieb Emil Velikov:
Signed-off-by: Emil Velikov
Well, any halve way sane compiler should be able to optimize that
anyway, but on the other hand the patch looks good to me.
Reviewed-by: Christian König
---
src/gallium/state_trackers/vdpau/mixer.c | 5 ++---
1
e patch is: Reviewed-by: Christian König
---
src/gallium/auxiliary/vl/vl_mpeg12_decoder.c | 4 ++--
src/gallium/auxiliary/vl/vl_video_buffer.c | 2 +-
src/gallium/state_trackers/vdpau/surface.c | 2 +-
3 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/src/gallium/auxiliary/vl
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
NAK. Failing is actually not correct here, cause we can still make it
work by allocating the video buffer later on decoding or uploading of
imag
Am 17.08.2013 23:51, schrieb Emil Velikov:
Free any allocated memory and return BadAlloc if create_video_buffer()
has failed to create a buffer.
Signed-off-by: Emil Velikov
Reviewed-by: Christian König
---
src/gallium/state_trackers/xvmc/surface.c | 4
1 file changed, 4 insertions
Am 17.08.2013 23:51, schrieb Emil Velikov:
Check if we have successfully allocated memory.
Signed-off-by: Emil Velikov
Reviewed-by: Christian König
---
src/gallium/auxiliary/vl/vl_video_buffer.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/src/gallium/auxiliary/vl
.
Reviewed-by: Christian König
---
src/gallium/auxiliary/vl/vl_mpeg12_decoder.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/gallium/auxiliary/vl/vl_mpeg12_decoder.c
b/src/gallium/auxiliary/vl/vl_mpeg12_decoder.c
index de890fe..cff326f 100644
--- a/src/gallium/auxiliary/vl
Am 17.08.2013 23:51, schrieb Emil Velikov:
Signed-off-by: Emil Velikov
Reviewed-by: Christian König
---
src/gallium/auxiliary/vl/vl_video_buffer.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/src/gallium/auxiliary/vl/vl_video_buffer.c
b/src/gallium
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
NAK. Failing is actually not correct here, cause we can
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
Reviewed-by: Christian König
Do you have commit access? And by the way I have enough on my to do list
for the VDPAU state
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
Reviewed-by: Christian König
Do you have
Reviewed and committed both patches.
Thanks for the help,
Christian.
Am 21.08.2013 10:06, schrieb Rico Schüller:
---
src/gallium/state_trackers/vdpau/query.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
___
mesa-dev mailing list
me
Am 22.08.2013 18:20, schrieb Vadim Girlin:
Signed-off-by: Vadim Girlin
Sounds good if it's stable enough.
Reviewed-by: Christian König
---
src/gallium/drivers/r600/r600_asm.c| 3 ++-
src/gallium/drivers/r600/r600_pipe.c | 4 ++--
src/gallium/drivers/r600/r600_pipe.h
Am 24.08.2013 03:30, schrieb Vadim Girlin:
Currently llvm backend always exports at least one color in pixel
shader even if no color buffers are enabled. With depth/stencil exports
this can result in the following code:
EXPORT PIXEL 0 R0.xyzw VPM
EXPORT PIXEL 61R
initialized earlier wasn't obviously to me.
Patch is: Reviewed-by: Christian König
---
src/gallium/drivers/nv50/nv98_video.c | 2 +-
src/gallium/drivers/nvc0/nvc0_video.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/gallium/drivers/nv50/nv98_video.c
b/src/ga
Well, for this discussion let's just assume that we fixed the delay in
the upper layers of the stack and the driver sees the shader code as
soon as the application (if I understood it correctly Vadim has just
volunteered for the job).
Also let's assume that shaders are small and having allot o
From: Christian König
Otherwise the first few frames have an incorrect reference index.
Signed-off-by: Christian König
---
src/gallium/drivers/radeon/radeon_uvd.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/gallium/drivers/radeon/radeon_uvd.c
b/src/gallium
Am 28.08.2013 19:17, schrieb Marek Olšák:
This series contains the changes my transform feedback work depends on, but
there are some useful fixes too, making it worth comitting earlier.
The last patch is the most important one, because it fixes the issues we had
with the emission of resource d
Am 29.08.2013 12:38, schrieb Marek Olšák:
On Thu, Aug 29, 2013 at 12:20 PM, Christian König
wrote:
Am 28.08.2013 19:17, schrieb Marek Olšák:
This series contains the changes my transform feedback work depends on,
but there are some useful fixes too, making it worth comitting earlier.
The
I was aware that this was only correct in one use case, but didn't know
which one. Probably should have added a comment about that.
Thanks for fixing it, both patches are: Reviewed-by: Christian König
Am 05.09.2013 16:41, schrieb Marek Olšák:
---
src/gallium/include
Actually Type 2 packets are handled much faster on the R6xx compared to
most type 3 packets, cause they are handled by the PFP/fetch hw and
doesn't need to be forwarded to the ME.
Christian.
Am 06.09.2013 02:31, schrieb Dominik Behr:
0x8000 is Type 2 NOP.
You could make it a little better
Am 06.09.2013 04:52, schrieb cee1:
2013/9/6 Jerome Glisse :
On Thu, Sep 05, 2013 at 03:29:52PM -0400, Jerome Glisse wrote:
On Thu, Sep 05, 2013 at 10:14:32PM +0800, Chen Jie wrote:
Hi all,
This thread is about
http://lists.freedesktop.org/archives/dri-devel/2013-April/037598.html.
We recentl
Am 06.09.2013 23:00, schrieb Alex Deucher:
This aligns the gfx, compute, and dma IBs to 8 DW boundries.
This aligns the the IB to the fetch size of the CP for optimal
performance. Additionally, r6xx hardware requires at least 4
DW alignment to avoid a hw bug. This also aligns the DMA
IBs to 8 DW
From: Christian König
Signed-off-by: Christian König
---
src/gallium/drivers/radeon/radeon_uvd.c |4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/src/gallium/drivers/radeon/radeon_uvd.c
b/src/gallium/drivers/radeon/radeon_uvd.c
index 5e7eedb..981d5c5 100644
--- a/src
From: Christian König
Move the code back into the common UVD files since we now
have base structures for R600 and radeonsi.
Signed-off-by: Christian König
---
src/gallium/drivers/r600/r600_pipe.c|2 +-
src/gallium/drivers/r600/r600_pipe.h|5 -
src/gallium/drivers
I completely agree.
Building everything shared might speed up the build process a little bit
and save some space, but for the cost of having to handle allot of
rather small shared libraries where which each clashing the symbol space
of any application using these drivers with a bunch of unnece
Am Donnerstag, 12. September 2013, 00:44:58 schrieb Kenneth Graunke:
On 09/11/2013 11:41 PM, Christian König wrote:
I completely agree.
Building everything shared might speed up the build process a little bit
and save some space, but for the cost of having to handle allot of
rather small shared
Reviewed and committed.
Thanks,
Christian.
- Ursprüngliche Mail -
Von: "Rico Schüller"
An: mesa-dev@lists.freedesktop.org
CC: "Rico Schüller"
Gesendet: Samstag, 14. September 2013 20:27:07
Betreff: [Mesa-dev] [PATCH] vdpau/decode: Check max width and max height.
---
src/galli
From: Christian König
v2: Actually implement interop between the gallium
state tracker and the VDPAU backend.
Signed-off-by: Christian König
---
src/gallium/include/state_tracker/vdpau_interop.h | 49
src/gallium/state_trackers/vdpau/ftab.c | 31 ++-
src/gallium
Am 20.09.2013 17:39, schrieb Marek Olšák:
On Fri, Sep 20, 2013 at 4:34 PM, Christian König
wrote:
[SNIP]
diff --git a/src/mesa/main/extensions.c b/src/mesa/main/extensions.c
index 34615e3..7070812 100644
--- a/src/mesa/main/extensions.c
+++ b/src/mesa/main/extensions.c
@@ -332,6 +332,7
From: Christian König
Share the winsys between different fd's if they point to the same device.
Signed-off-by: Christian König
---
src/gallium/winsys/radeon/drm/radeon_drm_winsys.c | 19 +--
1 file changed, 17 insertions(+), 2 deletions(-)
diff --git a/src/gallium/w
From: Christian König
v2: Actually implement interop between the gallium
state tracker and the VDPAU backend.
v3: Make it also available in non legacy contexts,
fix video buffer sharing.
Signed-off-by: Christian König
---
src/gallium/include/state_tracker/vdpau_interop.h | 49
From: Christian König
Kill the thread only after we checked that it's not used any more, not before.
Signed-off-by: Christian König
---
src/gallium/winsys/radeon/drm/radeon_drm_winsys.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/src/gallium/winsys/radeo
From: Christian König
v2: Actually implement interop between the gallium
state tracker and the VDPAU backend.
v3: Make it also available in non legacy contexts,
fix video buffer sharing.
Signed-off-by: Christian König
---
src/gallium/include/state_tracker/vdpau_interop.h | 49
From: Christian König
No need to block for the CS thread here.
Signed-off-by: Christian König
---
src/gallium/drivers/radeon/radeon_uvd.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/gallium/drivers/radeon/radeon_uvd.c
b/src/gallium/drivers/radeon/radeon_uvd.c
From: Christian König
Share the winsys between different fd's if they point to the same device.
Signed-off-by: Christian König
---
src/gallium/winsys/radeon/drm/radeon_drm_winsys.c | 19 +--
1 file changed, 17 insertions(+), 2 deletions(-)
diff --git a/src/gallium/w
From: Christian König
Waiting for an empty queue is nonsense and can lead to deadlocks if we have
multiple waiters or another thread that continuously sends down new commands.
Just post the cs to the queue and immediately wait for it to finish.
This is a candidate for the stable branch
l VDPAU textures should be
y-inverted. Is that actually the case here?
8) Do we actually have enough tests, so that we can say this feature works?
Marek
On Sat, Sep 21, 2013 at 12:32 PM, Christian König
wrote:
From: Christian König
v2: Actually implement interop between the gallium
state t
Am 21.09.2013 17:35, schrieb Stephan Raue:
Am 21.09.2013 16:56, schrieb Marek Olšák:
8) Do we actually have enough tests, so that we can say this feature
works?
I have integrated v2 of this patches yesterday in OpenELEC, an
embedded XBMC distro and it looks already nice. I will start to cr
Am 22.09.2013 22:29, schrieb Emil Velikov:
Signed-off-by: Emil Velikov
While it's not absolutely necessary for the VDPAU state tracker it makes
sense consequently use Makefile.source all around the place.
Reviewed-by: Christian König
---
src/gallium/state_trackers/vdpau/Makefi
Am 22.09.2013 22:29, schrieb Emil Velikov:
Signed-off-by: Emil Velikov
Reviewed-by: Christian König
---
src/gallium/state_trackers/xvmc/Makefile.am | 8 ++--
src/gallium/state_trackers/xvmc/Makefile.sources | 6 ++
2 files changed, 8 insertions(+), 6 deletions(-)
create
From: Christian König
Signed-off-by: Christian König
---
src/gallium/state_trackers/vdpau/decode.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/src/gallium/state_trackers/vdpau/decode.c
b/src/gallium/state_trackers/vdpau/decode.c
index b144b83..e884fb2 100644
--- a
From: Christian König
Signed-off-by: Christian König
---
src/gallium/auxiliary/vl/vl_mpeg12_bitstream.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/gallium/auxiliary/vl/vl_mpeg12_bitstream.c
b/src/gallium/auxiliary/vl/vl_mpeg12_bitstream.c
index cfa5eab..b03ad07
From: Christian König
Commonly used to find start codes and has far less overhead
to searching manually.
Signed-off-by: Christian König
---
src/gallium/auxiliary/vl/vl_vlc.h | 84 ++-
1 file changed, 74 insertions(+), 10 deletions(-)
diff --git a/src
From: Christian König
Signed-off-by: Christian König
---
src/gallium/state_trackers/vdpau/decode.c| 20 +++-
src/gallium/state_trackers/vdpau/vdpau_private.h | 1 +
2 files changed, 12 insertions(+), 9 deletions(-)
diff --git a/src/gallium/state_trackers/vdpau
From: Christian König
This is only supported on NI+, but the kernel takes care of those limitations.
Signed-off-by: Christian König
---
src/gallium/drivers/radeon/radeon_uvd.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/gallium/drivers/radeon/radeon_uvd.c
b
From: Christian König
Similar to GFX and DMA.
Signed-off-by: Christian König
---
src/gallium/drivers/radeon/radeon_uvd.c | 6 --
src/gallium/winsys/radeon/drm/radeon_drm_cs.c | 6 ++
2 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/src/gallium/drivers/radeon
From: Christian König
Only create one screen for each winsys instance.
This helps with buffer sharing and interop handling.
Signed-off-by: Christian König
---
src/gallium/drivers/r300/r300_screen.c| 3 +++
src/gallium/drivers/r600/r600_pipe.c | 3 +++
src/gallium
Why should that be necessary?
Christian.
Am 23.09.2013 21:09, schrieb mar...@gmail.com:
From: Marek Olšák
This fixes piglit:
- shaders/glsl-fs-texture2d-masked
- shaders/glsl-fs-texture2d-masked-4
Signed-off-by: Marek Olšák
---
lib/Target/R600/SIISelLowering.cpp | 27 +
|xvmc
...
radeonsi
|-dri
|-vdpau
|-xorg
...
Christian.
PS: Sorry that I send this mail from the AMD address, but my mail
provider once more has server problems.
Marek
On Mon, Sep 23, 2013 at 3:58 PM, Christian König
wrote:
From: Christian König
Only create one screen for each winsys insta
, 2013 at 9:00 AM, Christian König
wrote:
Why should that be necessary?
Christian.
Am 23.09.2013 21:09, schrieb mar...@gmail.com:
From: Marek Olšák
This fixes piglit:
- shaders/glsl-fs-texture2d-masked
- shaders/glsl-fs-texture2d-masked-4
Signed-off-by: Marek Olšák
---
lib/Target/R600
. Maybe some pass is executed twice?
Marek
On Tue, Sep 24, 2013 at 11:48 AM, Christian König
wrote:
Sorry, my fault let me refine the question: Why the heck is the function
applied twice?
Christian.
Am 24.09.2013 11:44, schrieb Marek Olšák:
If the TGSI writemask is .xzw and the initial dma
From: Christian König
Allows us to share more code between different targets.
Signed-off-by: Christian König
---
configure.ac | 8 ++--
src/gallium/targets/Makefile.am| 6 +--
src/gallium/targets/dri-r300/Makefile.am | 72
From: Christian König
Only create one screen for each winsys instance.
This helps with buffer sharing and interop handling.
v2: rebased and some minor cleanup
Signed-off-by: Christian König
---
src/gallium/drivers/r300/r300_screen.c| 3 +++
src/gallium/drivers/r600/r600_pipe.c
From: Christian König
Allows us to share more code between different targets.
Signed-off-by: Christian König
---
configure.ac | 8 +-
src/gallium/targets/Makefile.am| 6 +-
src/gallium/targets/dri-radeonsi/Makefile.am | 72
Am 26.09.2013 03:35, schrieb Marek Olšák:
Nothing too exciting, I'm just consolidating some code between r600g and
radeonsi. There are some small improvements though:
1) The CMASK buffer for MSAA colorbuffers is cleared with CP DMA instead of
using the CPU.
2) This series enables 2D tiling for
From: Christian König
No need to keep a copy of the message in system memory anymore,
since it should now be in GART memory on newer chips.
Signed-off-by: Christian König
---
src/gallium/drivers/radeon/radeon_uvd.c | 97 ++---
1 file changed, 53 insertions(+), 44
From: Christian König
Export only the absolutely necessary symbols in radeon vdpau targets.
Signed-off-by: Christian König
---
src/gallium/targets/r300/vdpau/Makefile.am | 3 +++
src/gallium/targets/r600/vdpau/Makefile.am | 3 +++
src/gallium/targets/radeonsi/vdpau/Makefile.am | 3
Am 12.02.2013 21:49, schrieb Michel Dänzer:
On Die, 2013-02-12 at 18:13 +0100, Christian König wrote:
From: Christian König
Mark all the operands that can also have an immediate.
Signed-off-by: Christian König
---
lib/Target/R600/SIInstrFormats.td | 32 +-
lib/Target/R600
Am 13.02.2013 01:20, schrieb Tom Stellard:
On Tue, Feb 12, 2013 at 06:13:19PM +0100, Christian König wrote:
From: Christian König
SIInstrFormats.td should contain the instruction encoding definitions
and everything else should go in SIInstrInfo.td. I got this backwards,
when I first created
Am 13.02.2013 01:39, schrieb Tom Stellard:
[SNIP]
Way back when I first started working on the backend I was using
immediate operands in instructions defined to only uses registers, and
it worked most of the time, but I ran into a few cases where some of the
passes weren't able to handle it. So
Am 13.02.2013 08:00, schrieb Michel Dänzer:
On Die, 2013-02-12 at 19:39 -0500, Tom Stellard wrote:
On Tue, Feb 12, 2013 at 06:13:22PM +0100, Christian König wrote:
From: Christian König
Seems to be allot simpler, and also paves the
way for further improvements.
[...]
diff --git a/lib
Am 13.02.2013 17:07, schrieb Michel Dänzer:
From: Michel Dänzer
The important fix is that the constant interpolation value is stored in the
parameter slot P0, which is encoded as 2.
In addition, pass the parameter slot as an operand to V_INTERP_MOV_F32
instead of hardcoding it there, and add a
Am 13.02.2013 18:11, schrieb Michel Dänzer:
On Mit, 2013-02-13 at 11:34 -0500, Tom Stellard wrote:
There's just the one cleanup on patch 10 that you mentioned, but
otherwise the series looks good to me. Should we mark all these patches
as candidates for the stable branch?
I think so, at least
Am 14.02.2013 09:20, schrieb Michel Dänzer:
On Die, 2013-02-12 at 15:22 +0100, Tom Stellard wrote:
Reviewed-by: Tom Stellard
Thanks, committed as revision 175138. Unfortunately, I only noticed
afterwards that the new SI test failed an assertion on trunk, see below.
I committed revision 175139
Am 13.02.2013 18:22, schrieb Michel Dänzer:
On Mit, 2013-02-13 at 18:17 +0100, Christian König wrote:
Am 13.02.2013 18:11, schrieb Michel Dänzer:
On Mit, 2013-02-13 at 11:34 -0500, Tom Stellard wrote:
There's just the one cleanup on patch 10 that you mentioned, but
otherwise the series
Hi Vadim,
nice work, I think you've made quite a progress here, but on the other
hand it should be clear that the LLVM backend is the future and we
should concentrate on that.
To sum it up I'm not sure what we should do with this branch :)
As Dragomir already wrote even if the code won't be
From: Christian König
Using the new NearestCommonDominator class.
Signed-off-by: Christian König
---
lib/Target/R600/AMDGPUStructurizeCFG.cpp |6 ++
1 file changed, 6 insertions(+)
diff --git a/lib/Target/R600/AMDGPUStructurizeCFG.cpp
b/lib/Target/R600/AMDGPUStructurizeCFG.cpp
index
301 - 400 of 1819 matches
Mail list logo
