From: Christian König christian.koe...@amd.com
Signed-off-by: Christian König christian.koe...@amd.com
---
configure.ac | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/configure.ac b/configure.ac
index bef5753..59b90e6 100644
--- a/configure.ac
+++ b/configure.ac
From: Christian König christian.koe...@amd.com
Signed-off-by: Christian König christian.koe...@amd.com
---
configure.ac | 7 ++-
1 file changed, 2 insertions(+), 5 deletions(-)
diff --git a/configure.ac b/configure.ac
index bc589b7..c37018f 100644
--- a/configure.ac
+++ b/configure.ac
From: Christian König christian.koe...@amd.com
We don't have GALLIUM_STATE_TRACKERS_DIRS any more.
Signed-off-by: Christian König christian.koe...@amd.com
---
configure.ac | 1 -
1 file changed, 1 deletion(-)
diff --git a/configure.ac b/configure.ac
index c37018f..bef5753 100644
From: Christian König christian.koe...@amd.com
This reverts commit bbe6f7f865cd4316b5f885507ee0b128a20686eb.
Signed-off-by: Christian König christian.koe...@amd.com
---
configure.ac | 11 +++
1 file changed, 3 insertions(+), 8 deletions(-)
diff --git a/configure.ac b/configure.ac
index
, Oct 6, 2014 at 11:31 AM, Emil Velikov emil.l.veli...@gmail.com wrote:
On 05/10/14 01:26, Ilia Mirkin wrote:
On Fri, Oct 3, 2014 at 3:43 AM, Christian König deathsim...@vodafone.de wrote:
Am 03.10.2014 um 03:53 schrieb Ilia Mirkin:
On Thu, Oct 2, 2014 at 7:59 PM, Emil Velikov emil.l.veli
Am 07.10.2014 um 15:07 schrieb Ilia Mirkin:
On Tue, Oct 7, 2014 at 9:04 AM, Christian König deathsim...@vodafone.de wrote:
Am 07.10.2014 um 03:11 schrieb Ilia Mirkin:
I'm under the assumption that OMX/etc don't do anything ridiculous. If
they do, it's a bug just like this vdpau situation
Am 03.10.2014 um 03:53 schrieb Ilia Mirkin:
On Thu, Oct 2, 2014 at 7:59 PM, Emil Velikov emil.l.veli...@gmail.com wrote:
On 02/10/14 06:41, Ilia Mirkin wrote:
On Mon, Sep 29, 2014 at 8:33 PM, Emil Velikov emil.l.veli...@gmail.com wrote:
On 29/09/14 17:24, Matt Turner wrote:
On Mon, Sep 29,
Am 02.10.2014 um 22:37 schrieb Alex Deucher:
On Thu, Oct 2, 2014 at 1:51 PM, Christian König deathsim...@vodafone.de wrote:
Am 02.10.2014 um 19:34 schrieb Marek Olšák:
From: Marek Olšák marek.ol...@amd.com
This fixes a crash when exiting Firefox. I have really no idea how Firefox
does
Am 02.10.2014 um 19:34 schrieb Marek Olšák:
From: Marek Olšák marek.ol...@amd.com
This fixes a crash when exiting Firefox. I have really no idea how Firefox
does it. It seems to involve multiple contexts and multithreading.
That looks to me like we now release all sampler views with the
Am 28.09.2014 um 22:13 schrieb Ilia Mirkin:
On Sun, Sep 28, 2014 at 4:09 PM, Emil Velikov emil.l.veli...@gmail.com wrote:
On 28/09/14 20:08, Emil Velikov wrote:
On 28/09/14 19:04, Ilia Mirkin wrote:
On Sun, Sep 28, 2014 at 1:35 PM, Emil Velikov emil.l.veli...@gmail.com wrote:
[snip]
This,
How about assuming for each CS that it can use the compute ring and as
soon as we submit a PM4 command that can only be executed on the
graphics ring note that this CS needs to be executed on the graphics ring?
Just an idea,
Christian.
Am 25.09.2014 um 21:02 schrieb Tom Stellard:
On Mon, Sep
Don't mean to come as rude, but did you even build the series ? It seems
to be failing on my system.
On 24/09/14 18:46, Leo Liu wrote:
From: Christian König christian.koe...@amd.com
This patch adds a skeleton VA-API state tracker,
which is filled with live in the subsequent patches.
v2: fixes
look into it.
Thanks a lot for doing this, patch is Reviewed-by: Christian König
christian.koe...@amd.com
---
configure.ac | 15 ---
src/gallium/auxiliary/Makefile.am| 23
src/gallium/auxiliary/Makefile.sources | 39
of specialized targets? E.g. what we might want to do is providing
Ubuntu/Debian packages with only the AMD drivers compiled into a
specialized dri_radeon.so etc...
The patch itself looks good to be, but I'm not an expert on automake. So
it is Acked-by: Christian König christian.koe...@amd.com
From: Christian König christian.koe...@amd.com
Signed-off-by: Christian König christian.koe...@amd.com
---
src/gallium/winsys/radeon/drm/radeon_drm_bo.h | 3 +++
src/gallium/winsys/radeon/drm/radeon_drm_cs.c | 11 +--
src/gallium/winsys/radeon/drm/radeon_drm_cs.h | 2 +-
3 files
From: Christian König christian.koe...@amd.com
Old kernels that don't know the chunk should simply ignore it.
Signed-off-by: Christian König christian.koe...@amd.com
---
src/gallium/winsys/radeon/drm/radeon_drm_cs.c | 14 ++
1 file changed, 2 insertions(+), 12 deletions(-)
diff
From: Christian König christian.koe...@amd.com
For now syncs all engines accessing a BO using the
new kernel interface, older kernels should ignore
the new chunk and maintain the old behavior.
Signed-off-by: Christian König christian.koe...@amd.com
---
src/gallium/winsys/radeon/drm
From: Christian König christian.koe...@amd.com
In preparation to using buffers clears with the hw engine(s).
v2: split out flipping to using hw buffer clears.
Signed-off-by: Christian König christian.koe...@amd.com
---
src/gallium/drivers/radeon/radeon_uvd.c| 40
From: Christian König christian.koe...@amd.com
Less CPU overhead and avoids contention over CPU accessible memory on startup.
Signed-off-by: Christian König christian.koe...@amd.com
---
src/gallium/drivers/radeon/radeon_uvd.c | 6 +++---
src/gallium/drivers/radeon/radeon_video.c | 10
From: Christian König christian.koe...@amd.com
This allows us to clear the video buffers using the gfx engine(s).
Signed-off-by: Christian König christian.koe...@amd.com
---
src/gallium/drivers/radeon/radeon_uvd.c| 46 +++---
src/gallium/drivers/radeon/radeon_vce.c
Am 02.09.2014 um 01:00 schrieb Dave Airlie:
From: Dave Airlie airl...@redhat.com
Coverity pointed out we never dropped the lock here, so fix
it by using a common exit path.
Signed-off-by: Dave Airlie airl...@redhat.com
Reviewed-by: Christian König christian.koe...@amd.com
---
src/gallium
-by: Christian König christian.koe...@amd.com
---
src/gallium/state_trackers/omx/vid_dec_h264.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/gallium/state_trackers/omx/vid_dec_h264.c
b/src/gallium/state_trackers/omx/vid_dec_h264.c
index 7f1c2fa..7b57785 100644
--- a/src/gallium
Am 29.08.2014 um 01:54 schrieb Grigori Goronzy:
On 04.07.2014 01:24, Andy Furniss wrote:
Maybe not 1/frame but anyway the first couple of a run have numbers
rather than s
[27977.386795] radeon :01:00.0: GPU fault detected: 146 0x0c035014
[27977.386800] radeon :01:00.0:
From: Christian König christian.koe...@amd.com
As long as we don't have a workaround for field based
decoding in VDPAu we should not advertise NV_vdpau_interop.
Signed-off-by: Christian König christian.koe...@amd.com
Cc: mesa-sta...@lists.freedesktop.org
---
src/mesa/state_tracker
Maybe a heretical thought, but how close are you guys to shortcut the
front end compiler with let's say the LLVM back end in radeonsi?
Regards,
Christian.
Am 29.08.2014 um 17:51 schrieb Greg Fischer:
Some additional information on GlassyMesa from the engineer who integrated
LunarGlass and
Dänzer michel.daen...@amd.com
This patch is Reviewed-by: Christian König christian.koe...@amd.com
I think we need a similar negative flags as well, e.g.
RADEON_GEM_NO_CPU_ACCESS.
This way we can stop forcing buffers into the visible VRAM while pinning
them for scanout.
Regards,
Christian
At least with the other components on which Mesa relies (e.g., libdrm,
2D drivers, etc.) it's largely the same group of people with the same
set of goals.
This was only true until Tom Stellard started to manage LLVM point releases.
Christian.
Am 28.08.2014 um 00:07 schrieb Ian Romanick:
On
Am 27.08.2014 um 05:09 schrieb Alex Deucher:
It doesn't seem to support field based decode after testing.
Signed-off-by: Alex Deucher alexander.deuc...@amd.com
Reviewed-by: Christian König christian.koe...@amd.com
---
src/gallium/drivers/radeon/radeon_video.c | 1 -
1 file changed, 1
Am 26.08.2014 um 03:54 schrieb Rob Clark:
On Wed, Aug 20, 2014 at 2:13 PM, Kenneth Graunke kenn...@whitecape.org wrote:
we've already had problems where distros refused to ship newer Mesa
releases because radeon depended on a version of LLVM newer than the
one they were shipping, [...]
That's
Am 26.08.2014 um 18:00 schrieb Jose Fonseca:
On 26/08/14 10:04, Christian König wrote:
Am 26.08.2014 um 03:54 schrieb Rob Clark:
On Wed, Aug 20, 2014 at 2:13 PM, Kenneth Graunke
kenn...@whitecape.org wrote:
we've already had problems where distros refused to ship newer Mesa
releases because
Am 26.08.2014 um 18:50 schrieb Emil Velikov:
On 15/08/14 19:33, Emil Velikov wrote:
On 14/08/14 10:59, Christian König wrote:
From: Christian König christian.koe...@amd.com
Correctly handle that the source_surface is only optional.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id
From: Christian König christian.koe...@amd.com
The first UVD generation can only do frame based output.
Signed-off-by: Christian König christian.koe...@amd.com
---
src/gallium/drivers/radeon/radeon_video.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/src/gallium
Am 22.08.2014 um 18:01 schrieb Connor Abbott:
On Fri, Aug 22, 2014 at 11:27 AM, Christian König
deathsim...@vodafone.de wrote:
Am 22.08.2014 um 17:13 schrieb Connor Abbott:
On Thu, Aug 21, 2014 at 11:08 PM, Dave Airlie airl...@gmail.com wrote:
On 22 August 2014 12:46, Jason Ekstrand ja
Am 22.08.2014 um 17:13 schrieb Connor Abbott:
On Thu, Aug 21, 2014 at 11:08 PM, Dave Airlie airl...@gmail.com wrote:
On 22 August 2014 12:46, Jason Ekstrand ja...@jlekstrand.net wrote:
On Thu, Aug 21, 2014 at 7:36 PM, Dave Airlie airl...@gmail.com wrote:
On 21 August 2014 19:10, Henri Verbeet
a lot of quads it might actually worth it.
Anyway the patch itself looks good and is Reviewed-by: Christian König
christian.koe...@amd.com
---
src/gallium/auxiliary/tgsi/tgsi_strings.c | 3 ++-
src/gallium/auxiliary/util/u_prim.h | 1 +
src/gallium/docs/source/screen.rst
I think we can fix this by introducing new structured variants of the
branch instruction in a way that doesn't alter the fundamental structure
of the IR. E.g. an if branch could look like:
ifbr i1 cond, label iftrue, label iffalse, label join
Where both branches are guaranteed to converge at
Am 20.08.2014 um 14:33 schrieb Connor Abbott:
On Tue, Aug 19, 2014 at 11:57 PM, Christian König
deathsim...@vodafone.de wrote:
I think we can fix this by introducing new structured variants of the
branch instruction in a way that doesn't alter the fundamental structure
of the IR. E.g
Am 19.08.2014 um 01:20 schrieb Emil Velikov:
This define is always set and it had no real purpose according to
git log. Seems like it is a leftover from the vl/vdpau prototype
stage.
Cc: Christian König christian.koe...@amd.com
Signed-off-by: Emil Velikov emil.l.veli...@gmail.com
Reviewed
Am 19.08.2014 um 01:20 schrieb Emil Velikov:
Signed-off-by: Emil Velikov emil.l.veli...@gmail.com
Is it necessary to sort the files by name? They where more or less
sorted by importance and time of creation in the VDPAU interface.
Christian.
---
Am 19.08.2014 um 01:20 schrieb Emil Velikov:
... and add the headers so that 'make check' is happy.
Cc: Christian König christian.koe...@amd.com
Signed-off-by: Emil Velikov emil.l.veli...@gmail.com
Reviewed-by: Christian König christian.koe...@amd.com
---
src/gallium/state_trackers/omx
Am 19.08.2014 um 11:09 schrieb Emil Velikov:
On 19/08/14 09:59, Christian König wrote:
Am 19.08.2014 um 01:20 schrieb Emil Velikov:
Signed-off-by: Emil Velikov emil.l.veli...@gmail.com
Is it necessary to sort the files by name? They where more or less sorted by
importance and time of creation
From: Christian König christian.koe...@amd.com
Otherwise we clear areas that shouldn't be cleared.
Signed-off-by: Christian König christian.koe...@amd.com
---
src/gallium/auxiliary/vl/vl_compositor.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/gallium/auxiliary/vl
From: Christian König christian.koe...@amd.com
Correctly handle that the source_surface is only optional.
Signed-off-by: Christian König christian.koe...@amd.com
---
src/gallium/state_trackers/vdpau/device.c| 43 +++-
src/gallium/state_trackers/vdpau/output.c
From: Christian König christian.koe...@amd.com
This fixes an issue with flash where it tries to destroy a decoder
after already destroying the device associated with the decoder.
Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=82517
Signed-off-by: Christian König christian.koe...@amd.com
Am 13.08.2014 um 17:13 schrieb Ilia Mirkin:
On Wed, Aug 13, 2014 at 11:07 AM, Christian König
deathsim...@vodafone.de wrote:
From: Christian König christian.koe...@amd.com
This fixes an issue with flash where it tries to destroy a decoder
after already destroying the device associated
Am 06.08.2014 um 23:49 schrieb Marek Olšák:
From: Marek Olšák marek.ol...@amd.com
Wanted to do this for a while as well.
The whole series is: Reviewed-by: Christian König christian.koe...@amd.com
R600-R700 don't support virtual memory.
---
src/gallium/drivers/r600/r600_state.c | 27
From: Christian König christian.koe...@amd.com
Signed-off-by: Christian König christian.koe...@amd.com
---
src/gallium/auxiliary/pipebuffer/pb_buffer.h | 2 +-
src/gallium/winsys/radeon/drm/radeon_drm_bo.c | 2 +-
src/gallium/winsys/radeon/drm/radeon_drm_cs.c | 3 ++-
3 files changed, 4
:24 schrieb Marek Olšák:
What is this patch good for?
Marek
On Tue, Aug 5, 2014 at 7:31 PM, Christian König deathsim...@vodafone.de wrote:
From: Christian König christian.koe...@amd.com
Signed-off-by: Christian König christian.koe...@amd.com
---
src/gallium/drivers/radeon/r600_pipe_common.c
König deathsim...@vodafone.de wrote:
From: Christian König christian.koe...@amd.com
v2: fix a couple of typos and bugs
Signed-off-by: Christian König christian.koe...@amd.com
---
src/gallium/drivers/radeonsi/si_dma.c | 85 +++
src/gallium/drivers/radeonsi/sid.h
Am 06.08.2014 um 13:45 schrieb Marek Olšák:
On Tue, Aug 5, 2014 at 7:31 PM, Christian König deathsim...@vodafone.de wrote:
From: Christian König christian.koe...@amd.com
Not completely implemented, cause we need DMA copy support for every hw
generation.
Signed-off-by: Christian König
From: Christian König christian.koe...@amd.com
Signed-off-by: Christian König christian.koe...@amd.com
---
src/gallium/drivers/radeon/r600_pipe_common.c | 9 ++
src/gallium/drivers/radeon/r600_pipe_common.h | 11 +++
src/gallium/drivers/radeon/r600_texture.c | 41
From: Christian König christian.koe...@amd.com
v2: fix a couple of typos and bugs
Signed-off-by: Christian König christian.koe...@amd.com
---
src/gallium/drivers/radeonsi/si_dma.c | 85 +++
src/gallium/drivers/radeonsi/sid.h| 1 +
2 files changed, 68
From: Christian König christian.koe...@amd.com
Signed-off-by: Christian König christian.koe...@amd.com
---
src/gallium/winsys/radeon/drm/radeon_drm_bo.c | 102 ++
src/gallium/winsys/radeon/drm/radeon_winsys.h | 11 +++
2 files changed, 113 insertions(+)
diff --git a/src
From: Christian König christian.koe...@amd.com
Not completely implemented, cause we need DMA copy support for every hw
generation.
Signed-off-by: Christian König christian.koe...@amd.com
---
src/gallium/drivers/radeon/r600_buffer_common.c | 2 +-
src/gallium/drivers/radeon/r600_pipe_common.c
Am 04.08.2014 um 12:48 schrieb Andreas Boll:
The initial firmware for hawaii does not support type3 nop packet.
Detect the new hawaii firmware with query RADEON_INFO_ACCEL_WORKING2.
If the returned value is 3, then the new firmware is used.
This patch uses type2 for the old firmware and type3
Am 04.08.2014 um 12:48 schrieb Andreas Boll:
The initial firmware for hawaii does not support type3 nop packet.
Detect the new hawaii firmware with query RADEON_INFO_ACCEL_WORKING2.
If the returned value is 3, then the new firmware is used.
This patch uses type2 for the old firmware and type3
Am 31.07.2014 um 11:43 schrieb Michel Dänzer:
From: Michel Dänzer michel.daen...@amd.com
Signed-off-by: Michel Dänzer michel.daen...@amd.com
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
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 michel.daen...@amd.com
Signed-off-by: Michel Dänzer michel.daen...@amd.com
At least for PIPE_USAGE_STREAM buffers that's a bad idea
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
I'm still
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 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 why it's faster
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
: 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 christian.koe...@amd.com
[PATCH 5/5] drm/radeon: Use VRAM for indirect buffers on = SI
I'm
module.
Small typo gellium instead of gallium.
Signed-off-by: Emil Velikov emil.l.veli...@gmail.com
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
christian.koe...@amd.com
Regards,
Christian
From: Christian König christian.koe...@amd.com
Signed-off-by: Christian König christian.koe...@amd.com
---
src/gallium/drivers/radeonsi/si_dma.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/src/gallium/drivers/radeonsi/si_dma.c
b/src/gallium/drivers/radeonsi/si_dma.c
From: Christian König christian.koe...@amd.com
We want hex values here, not decimals.
Signed-off-by: Christian König christian.koe...@amd.com
---
src/gallium/drivers/radeon/r600_buffer_common.c | 2 +-
src/gallium/drivers/radeon/r600_texture.c | 2 +-
2 files changed, 2 insertions(+), 2
...@gmail.com
Reviewed-by: Christian König christian.koe...@amd.com
---
src/gallium/state_trackers/omx/vid_dec.c | 41 ++--
src/gallium/state_trackers/omx/vid_enc.c | 20 ++--
2 files changed, 52 insertions(+), 9 deletions(-)
diff --git a/src/gallium
Hi Emil,
This patch is Reviewed-by: Christian König christian.koe...@amd.com
But there is still something looking odd:
if NEED_RADEON_DRM_WINSYS
if !HAVE_GALLIUM_R300
-if !HAVE_GALLIUM_RADEONSI
STATIC_TARGET_LIB_DEPS += \
$(top_builddir)/src/gallium/winsys/radeon/drm
Am 17.06.2014 20:02, schrieb Emil Velikov:
The r600 equivalent of previous commit.
v2:
- Correctly include the radeon winsys/radeon_common.
Cc: Christian König christian.koe...@amd.com
Signed-off-by: Emil Velikov emil.l.veli...@gmail.com
Reviewed-by: Christian König christian.koe
König christian.koe...@amd.com
Signed-off-by: Emil Velikov emil.l.veli...@gmail.com
Reviewed-by: Christian König christian.koe...@amd.com
---
configure.ac | 3 +-
src/gallium/targets/Makefile.am | 4 ---
src/gallium/targets/omx/Makefile.am | 21
König christian.koe...@amd.com
Signed-off-by: Emil Velikov emil.l.veli...@gmail.com
Reviewed-by: Christian König christian.koe...@amd.com
---
configure.ac | 3 +-
src/gallium/Automake.inc | 21
src/gallium/targets/Makefile.am
Am 17.06.2014 20:06, schrieb Emil Velikov:
Similar to previous commit, this allows us to minimise some
of the duplication by compacting all vdpau targets into a
single library.
v2:
- Include the radeon winsys only when there is a user for it.
Cc: Christian König christian.koe...@amd.com
Am 17.06.2014 20:38, schrieb Emil Velikov:
Related to previous commit, merge the separate dri targets to a single
one.
This is essentially all the buildsystem mayhem required for megaradeon.
Cc: Marek Olšák marek.ol...@amd.com
Cc: Michel Dänzer michel.daen...@amd.com
Cc: Christian König
@Grigori: Should I push it or did you got your account in the meantime?
Christian.
Am 17.06.2014 22:26, schrieb Marek Olšák:
This looks good to me.
Reviewed-by: Marek Olšák marek.ol...@amd.com
Marek
On Wed, Jun 4, 2014 at 6:54 PM, Grigori Goronzy g...@chown.ath.cx wrote:
This makes 4:2:2
Ok, pushed the patches.
Account requests usually take a while to complete, that's nothing to
worry about.
Regards,
Christian.
Am 18.06.2014 13:14, schrieb Grigori Goronzy:
On 18.06.2014 13:11, Christian König wrote:
@Grigori: Should I push it or did you got your account in the meantime
Am 12.06.2014 18:27, schrieb Leo Liu:
Signed-off-by: Leo Liu leo@amd.com
I've pushed everything upstream.
Thanks for the help,
Christian.
---
src/gallium/state_trackers/omx/vid_enc.c | 32
1 file changed, 16 insertions(+), 16 deletions(-)
diff --git
Yeah, agree adding SDNodes for every intrinsic sounds odd.
SDNodes should be the source of the selection process, not it's destination.
Christian.
Am 17.06.2014 03:51, schrieb Marek Olšák:
Is there any specific reason for using SDNodes for everything?
Using intrinsics directly in patterns
obviously wrong and should be fixed. Patch is
Reviewed-by: Christian König christian.koe...@amd.com
Regards,
Christian.
---
src/gallium/drivers/radeonsi/si_shader.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/gallium/drivers/radeonsi/si_shader.c
b/src/gallium
is Reviewed-by: Christian König christian.koe...@amd.com
---
configure.ac | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/configure.ac b/configure.ac
index 7b0009d..a19f777 100644
--- a/configure.ac
+++ b/configure.ac
@@ -1412,7 +1412,7 @@ AM_CONDITIONAL(HAVE_OPENVG, test x
an error check here that we don't have zero CPBs, that can
happen if the user specifies an invalid level for the given resolution.
In this case a goto error should probably be sufficient.
With that fixed the series is Reviewed-by: Christian König
christian.koe...@amd.com
Leave me a note
Am 04.06.2014 16:20, schrieb Andy Furniss:
Christian König wrote:
Reviewed and pushed.
Pushed where?
Unfortunately to the wrong server instead of upstream, thanks for the
notice.
I guess they don't affect radeon uvd anyway, just when I saw 422 and
444, I was hopeful that uvd cards would
Am 04.06.2014 18:54, schrieb Grigori Goronzy:
It's about as broken as on later UVD revisions.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=66452
Cc: 10.1 10.2 mesa-sta...@lists.freedesktop.org
Do you have commit rights?
Patch is Reviewed-by: Christian König christian.koe...@amd.com
Reviewed and pushed.
Thanks,
Christian.
Am 30.05.2014 21:57, schrieb Leo Liu:
Signed-off-by: Leo Liu leo@amd.com
---
src/gallium/auxiliary/util/u_video.h | 4
src/gallium/include/pipe/p_video_enums.h | 6 +-
2 files changed, 9 insertions(+), 1 deletion(-)
diff --git
Am 27.05.2014 16:12, schrieb Leo Liu:
Signed-off-by: Leo Liu leo@amd.com
Reviewed and pushed upstream.
Thanks,
Christian.
---
src/gallium/include/pipe/p_video_state.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/src/gallium/include/pipe/p_video_state.h
it this way.
BTW: I would prefer the name libomx_mesa.
Cheers,
Christian.
Cc: Christian König christian.koe...@amd.com
Signed-off-by: Emil Velikov emil.l.veli...@gmail.com
---
configure.ac | 5 +--
src/gallium/Automake.inc | 17
src
Am 15.05.2014 14:13, schrieb Emil Velikov:
On 15/05/14 03:33, Michel Dänzer wrote:
On 15.05.2014 10:58, Marek Olšák wrote:
Hi everybody,
Some distros seem to care about the size of Mesa, so I came up with
this little patch.
It puts r600g and radeonsi into r300_dri.so. The result is one
Am 14.05.2014 09:55, schrieb Michel Dänzer:
On 14.05.2014 06:45, Marek Olšák wrote:
From: Marek Olšák marek.ol...@amd.com
It works just fine.
This fixes a crash in:
piglit/spec/glsl-1.20/execution/fs-const-array-of-struct-of-array
Bugzilla:
Am 17.04.2014 18:19, schrieb Leo Liu:
From: Leo Liuleo@amd.com
Signed-off-by: Leo Liuleo@amd.com
Reviewed pushed.
Thanks,
Christian.
---
src/gallium/state_trackers/omx/vid_enc.c | 214 ++-
1 file changed, 185 insertions(+), 29 deletions(-)
diff
is probably easier for the CPU.
Marek
On Mon, Apr 14, 2014 at 2:41 PM, Marek Olšák mar...@gmail.com wrote:
Yes, I will remove the flag in the next patch series.
Marek
On Sun, Apr 13, 2014 at 10:45 AM, Christian König
deathsim...@vodafone.de wrote:
For this series: Reviewed-by: Christian König
For this series: Reviewed-by: Christian König christian.koe...@amd.com
BTW: Can we get rid of RADEON_FLUSH_ASYNC and always flush
asynchronously? Just calling cs_sync_flush directly after the flush
should have the same effect as synchronous flushing.
Christian.
Am 12.04.2014 18:34, schrieb
Am 11.04.2014 19:03, schrieb Marek Olšák:
From: Marek Olšák marek.ol...@amd.com
Reviewed-by: Christian König christian.koe...@amd.com
BTW:
I've always wondered if the custom hash table is the best approach here.
Having a BO active in more than one command submission context at the
same
this.
If we have O(1) anyway most of the time than changing it would probably
not make much sense.
Christian.
Marek
On Sat, Apr 12, 2014 at 10:35 AM, Christian König
deathsim...@vodafone.de wrote:
Am 11.04.2014 19:03, schrieb Marek Olšák:
From: Marek Olšák marek.ol...@amd.com
Reviewed
(GLintptr)NULL;
@@ -254,7 +254,7 @@ _mesa_VDPAUUnregisterSurfaceNV(GLintptr surface)
}
_mesa_set_remove(ctx-vdpSurfaces, entry);
- FREE(surf);
+ free(surf);
}
void GLAPIENTRY
Reviewed-by: Christian König christian.koe...@amd.com
___
mesa
Am 10.04.2014 03:26, schrieb Brian Paul:
We were using REALLOC() from u_memory.h but FREE() from imports.h.
This mismatch caused us to trash the heap on Windows after we
deleted a texture object.
This fixes a regression from commit 6c59be7776e4d.
Reviewed-by: Christian König christian.koe
:
Reviewed-by: Christian König christian.koe...@amd.com
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
From: Christian König christian.koe...@amd.com
Signed-off-by: Slava Grigorev slava.grigo...@amd.com
Signed-off-by: Christian König christian.koe...@amd.com
---
src/gallium/drivers/radeon/radeon_vce.h| 2 +-
src/gallium/drivers/radeon/radeon_vce_40_2_2.c | 73
From: Christian König christian.koe...@amd.com
Keep tasks as linked list, this way we can associate
more than one encoding task with each buffer.
Signed-off-by: Christian König christian.koe...@amd.com
---
src/gallium/state_trackers/omx/vid_enc.c | 182 +--
src
From: Christian König christian.koe...@amd.com
Doesn't seems to be needed any more.
Signed-off-by: Christian König christian.koe...@amd.com
---
src/gallium/drivers/radeon/radeon_vce.c| 2 +-
src/gallium/drivers/radeon/radeon_vce.h| 1 -
src/gallium/drivers/radeon
From: Christian König christian.koe...@amd.com
Signed-off-by: Christian König christian.koe...@amd.com
---
src/gallium/drivers/radeon/radeon_vce_40_2_2.c | 11 ++-
src/gallium/include/pipe/p_video_state.h | 3 +++
src/gallium/state_trackers/omx/vid_enc.c | 8 +++-
3
From: Christian König christian.koe...@amd.com
Remember what frames we encoded at which position.
Signed-off-by: Christian König christian.koe...@amd.com
---
src/gallium/drivers/radeon/radeon_vce.c| 87 --
src/gallium/drivers/radeon/radeon_vce.h| 15
701 - 800 of 1736 matches
Mail list logo
