On 2016-06-08 15:47, Borislav Petkov wrote:
> On Wed, Jun 08, 2016 at 03:30:34PM +0200, Christian König wrote:
>
>> Try forcing mplayer to use VDPAU with "mplayer -vo vdpau $file".
>
> All good. Actually, this hw accel thing is much better, I better make
> it
> default :-P
>
Are you sure it i
Fix a copy/paste error introduced by commit feebe91a, which backported
a stability fix from gfx_v8, but incorrectly forgot to dereference
into the sync_seq array, causing hangs as soon as acceleration was
used. The wait can't finish without the correct seq value.
Signed-off-by: Grigori Go
r.
>
> This fixes radeon_cursor_reset accidentally incrementing the cursor BO
> pin count, and cleans up the code a little.
>
Thank you for finishing this up!
Series is
Reviewed-by: Grigori Goronzy
> Cc: stable at vger.kernel.org
> Signed-off-by: Michel Dänzer
> ---
> d
On 2015-07-03 05:30, Michel Dänzer wrote:
>
> This could be done in the same loop as the front buffers.
>
Sure, I just thought it looks cleaner this way.
> On resume, the cursor BO is currently pinned again by
> radeon_cursor_reset -> radeon_set_cursor. However, radeon_cursor_reset
> is also c
: Grigori Goronzy
---
drivers/gpu/drm/radeon/radeon_device.c | 14 ++
1 file changed, 14 insertions(+)
diff --git a/drivers/gpu/drm/radeon/radeon_device.c
b/drivers/gpu/drm/radeon/radeon_device.c
index 14deeae..5df 100644
--- a/drivers/gpu/drm/radeon/radeon_device.c
+++ b/drivers
Signed-off-by: Grigori Goronzy
---
drivers/gpu/drm/radeon/radeon_device.c | 32 +++-
1 file changed, 19 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_device.c
b/drivers/gpu/drm/radeon/radeon_device.c
index a7fdfa4..14deeae 100644
--- a/drivers
This was regressed by commit 39e7f6f8, although I don't know of any
actual issues caused by it.
The storage domain is read without TTM locking now, but the lock
never helped to prevent any races.
Cc: stable at vger.kernel.org
Signed-off-by: Grigori Goronzy
---
drivers/gpu/drm/r
We don't need to call the (expensive) radeon_bo_wait, checking the
fences via RCU is much faster. The reservation done by radeon_bo_wait
does not save us from any race conditions.
Signed-off-by: Grigori Goronzy
---
drivers/gpu/drm/radeon/radeon_gem.c | 11 ---
1 file chang
On 2015-07-02 16:18, Alex Deucher wrote:
> On Wed, Jul 1, 2015 at 11:08 PM, Michel Dänzer
> wrote:
>> On 02.07.2015 06:20, Alex Deucher wrote:
>>>
>>> Alex Deucher (4):
>> [...]
>>> Revert "drm/radeon: dont switch vt on suspend"
>>
>> Do we have a plan for re-enabling this? It seems to w
Newer ASICs have more VRAM on average and allocating more GART as
well can have advantages. Also see commit edcd26e8.
Ideally, we should scale GART size based on actual VRAM size, but
that requires significant restructuring of initialization.
v2: extract small helper, apply to error paths
---
Sor
Newer ASICs have more VRAM on average and allocating more GART as
well can have advantages. Also see commit edcd26e8.
Ideally, we should scale GART size based on actual VRAM size, but
that requires significant restructuring of initialization.
---
drivers/gpu/drm/radeon/radeon_device.c | 4 +++-
1
This was regressed by commit 39e7f6f8, although I don't know of any
actual issues caused by it.
The storage domain is read without TTM locking now, but the lock
never helped to prevent any actual races.
Cc: stable at vger.kernel.org
---
drivers/gpu/drm/radeon/radeon_gem.c | 1 +
1 file changed,
We don't need to call the (expensive) radeon_bo_wait, checking the
fences via RCU is much faster. The reservation done by radeon_bo_wait
does not save us from any race conditions.
---
drivers/gpu/drm/radeon/radeon_gem.c | 11 ---
1 file changed, 8 insertions(+), 3 deletions(-)
diff --git
't fix the hangs.
Anyway,
Reviewed-By: Grigori Goronzy
Grigori
> Signed-off-by: Christian K?nig
> Cc: stable at vger.kernel.org
> ---
> drivers/gpu/drm/radeon/radeon_semaphore.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/ra
l be used for
overriding the automatic state decision. Systems which have "bad" (slow)
3D power levels in UVD power states should never choose dynamically.
They should use the generic UVD power state by default and users can
override it with the sysfs entry.
Grigori
>
>
>
For reference, I forgot to send to you all.
Forwarded Message
Subject: Re: [PATCH] drm/radeon: Adding UVD handle basis fps estimation v2
Date: Fri, 15 Aug 2014 18:40:02 +0200
From: Grigori Goronzy
To: Alex Deucher
On 15.08.2014 17:45, Alex Deucher wrote:
> Maybe I&#x
On 15.08.2014 17:26, Alex Deucher wrote:
> On Fri, Aug 15, 2014 at 11:20 AM, Grigori Goronzy
> wrote:
>> On 15.08.2014 16:11, Christian K?nig wrote:
>>> Hi Marco,
>>>
>>> the problem with an CS ioctl flag is that we sometimes don't know how
>>>
On 15.08.2014 16:11, Christian K?nig wrote:
> Hi Marco,
>
> the problem with an CS ioctl flag is that we sometimes don't know how
> much SCLK/MCLK boost is needed, for example when we do post processing
> in the player using OpenGL and UVD decoding with VDPAU. In this case
> VDPAU don't has the sl
Looks good, I think.
> vm_size vm_block_size
> 1GB=9
> 2GB=10
> 4GB=11
> 8GB=12
> 16GB =12
> 32GB =13
> 64GB =13
> 128GB=14
> 256GB=14
> 512GB = 15
> 1TB
On 18.07.2014 11:38, Christian K?nig wrote:
> From: Christian K?nig
>
> Signed-off-by: Christian K?nig
> ---
> drivers/gpu/drm/radeon/radeon_device.c | 6 +-
> drivers/gpu/drm/radeon/radeon_drv.c| 4 ++--
> 2 files changed, 7 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/d
On 18.07.2014 13:45, Marek Ol??k wrote:
> If the requirements of GL_MAP_COHERENT_BIT are satisfied, then the
> patch is okay.
>
Apart from correctness, I still wonder how this will affect performance,
most notably CPU reads. This change unconditionally uses write-combined,
uncached memory for MAP_
On 17.07.2014 12:01, Michel D?nzer wrote:
> From: Michel D?nzer
>
> This is hopefully safe: The kernel makes sure writes to these mappings
> finish before the GPU might start reading from them, and the GPU caches
> are invalidated at the start of a command stream.
>
Aren't CPU reads from write-c
On 30.05.2014 13:46, Grigori Goronzy wrote:
> On 30.05.2014 13:30, Marek Ol??k wrote:
>> Grigori,
>>
>> you can git-checkout the commit before and after the memory management
>> changes, compile both and test them.
>>
>
> I was trying to revert the changes,
heck out should be 0bc490a8
(before) and 19dff56a (after), right?
Best regards
Grigori
> Marek
>
> On Fri, May 30, 2014 at 2:30 AM, Grigori Goronzy wrote:
>> On 13.05.2014 22:27, Marek Ol??k wrote:
>>>
>>> I applied these two patches Christian sent to dri-deve
ut this is not
acceptable IMHO. I'll try to investigate further.
Best regards
Grigori
> Marek
>
> On Tue, May 13, 2014 at 10:19 PM, Grigori Goronzy
> wrote:
>> On 13.05.2014 21:50, Marek Ol??k wrote:
>>>
>>> Hi Christian,
>>>
>>> The p
;>> Kernel 3.14:
>>> real0m17.724s
>>> user0m41.905s
>>> sys0m11.299s
>>>
>>> The problematic commit checked out + your fixes (without the PTE patch I
>>> think):
>>> real0m23.474s
>&
Any idea what is wrong with it?
>>>>> Actually I already wondered that it went so smooth without any
>>>>> regression
>>>>> so far, didn't noticed the bug in bugzilla.kernel.org yet.
>>>>>
>>>>>> Some of the tests
On 09.05.2014 20:03, Marek Ol??k wrote:
>
> This commit which first appeared in 3.15-rc1 causes hangs on Bonaire:
>[...]
>
> The simplest way to reproduce the hangs is to run piglit with these
> parameters:
> -t texelFetch.fs
>
> Some of the tests allocate a lot of MSAA textures and the tests also
On 07.01.2014 16:14, Alex Deucher wrote:
> The hw i2c engines are disabled by default as the
> current implementation is still experimental. Print
> a warning when users enable it so that it's obvious
> when the option is enabled.
>
Does hardware I2C actually have any advantage in the DDC use cas
On 15.10.2013 20:12, Christian K?nig wrote:
> From: Christian K?nig
>
> This only seem to work for H.264 but not for VC-1 streams.
>
> Need to investigate further why exactly.
>
Thanks for the quick investigation. This is really strange. The
corruption looks very similar to what I saw with VC-1
On 30.09.2013 10:06, Michel Dänzer wrote:
On Son, 2013-09-29 at 22:34 +0200, Dieter Nützel wrote:
after latest git pull I've only MPEG1, MPEG2_SIMPLE and MPEG2_MAIN with
my RV730 (AGP).
Same problem on PALM. Bisection shows that it is caused by commit
68f6dec32. The initialization order se
On 21.08.2013 16:31, Boszormenyi Zoltan wrote:
> Hi,
>
> I read this Phoronix article:
> http://www.phoronix.com/scan.php?page=article&item=amd_hd6000_dpm&num=1
>
> Congrats to the progress achieved so far.
>
> However, I can see an interesting deviation for HD6570 from the
> observed trend of othe
On 21.08.2013 16:31, Boszormenyi Zoltan wrote:
Hi,
I read this Phoronix article:
http://www.phoronix.com/scan.php?page=article&item=amd_hd6000_dpm&num=1
Congrats to the progress achieved so far.
However, I can see an interesting deviation for HD6570 from the
observed trend of other chips.
r60
On 26.06.2013 23:57, Julian Wollrath wrote:
> Hi,
>
> I just tried the DPM support out on a E-450 APU (HD6320) and it did not
> work like expected. In the terminal everything seemed ok but when I
> started a display manager, the screen showed garbage and the system
> basically locked up. The radeon
On 26.06.2013 23:57, Julian Wollrath wrote:
Hi,
I just tried the DPM support out on a E-450 APU (HD6320) and it did not
work like expected. In the terminal everything seemed ok but when I
started a display manager, the screen showed garbage and the system
basically locked up. The radeon and drm
Hi,
I have a Lenovo X121e notebook, and the model variant in question uses
the E-450 APU. I have various problems with the GPU part of it. The most
severe seems to be that switching between power states does not work
correctly.
First off, the PowerPlay table looks rather strange. Here's what the
Hi,
I have a Lenovo X121e notebook, and the model variant in question uses
the E-450 APU. I have various problems with the GPU part of it. The most
severe seems to be that switching between power states does not work
correctly.
First off, the PowerPlay table looks rather strange. Here's what the
37 matches
Mail list logo
