Christian König wrote:
Otherwise buffer placement is very restrictive and might fail.
Fixes: "drm/amdgpu: fix VCE buffer placement restrictions v2"
Signed-off-by: Christian König
Reported-by: Deng, Emily
---
drivers/gpu/drm/amd/amdgpu/amdgpu_vce.c | 4 ++--
1 file changed, 2 insertions(+),
Andy Furniss wrote:
Christian König wrote:
Leo and Andy could you two give that patch set a try?
It should fix occasional VCE fall outs when by coincident a buffers is
placed on a 4GB boundary.
On drm-next-4.15 vanilla the corruption like in -
https://bugs.freedesktop.org/show_bug.cgi?id
Christian König wrote:
Leo and Andy could you two give that patch set a try?
It should fix occasional VCE fall outs when by coincident a buffers is
placed on a 4GB boundary.
On drm-next-4.15 vanilla the corruption like in -
https://bugs.freedesktop.org/show_bug.cgi?id=102296
is still presen
Andy Furniss wrote:
On 4.15-wip with patches that make powerplay work I have an issue with
one game = unreal tournament alpha.
This doesn't seem to affect other things like xonotic or unigine demos.
Issue = on fixes 4.14 and other older kernels I've tried, the game is OK
ish perf w
On 4.15-wip with patches that make powerplay work I have an issue with
one game = unreal tournament alpha.
This doesn't seem to affect other things like xonotic or unigine demos.
Issue = on fixes 4.14 and other older kernels I've tried, the game is OK
ish perf wise, 20-40 fps.
On 4.15-wip it
These also fix for me.
Testing with 4.15-wip I also need the partial revert patch.
Tom St Denis wrote:
Hi Rex,
Thanks. Everything seems to be functional again on my Tonga.
Cheers,
Tom
On 06/10/17 01:18 AM, Rex Zhu wrote:
regresstion issue caused by
commit 47047263c52779f1f3393c32e3e53661b53
For me testing on 4.15-wip with tonga it does "fix", but memclk is
stuck, which would have avoided the lines had I forced it without this.
Maybe you see different on a different kernel - is memclk stuck for you
with this?
Tom St Denis wrote:
This partially reverts 0b6b4cbf77c995a34a4ec3d705a
Martin Babutzka wrote:
2. Flicker issue: As wrote in my last mail the amd-staging-drm-next
causes heavy flickering horizontal lines. Had to do a large bisect
to find the bad commit. No idea what is precisely broken there but I
hope this helps to resolve it.
I bisected to the same commit for t
Alex Deucher wrote:
On Fri, Jul 28, 2017 at 6:08 PM, Andy Furniss wrote:
Alex Deucher wrote:
May waste a bit of memory, but simplifies the interface
significantly.
Can't boot tonga with this (testing 4.14-wip)
Should be fixed with this patch.
Yes, OK with that, t
Alex Deucher wrote:
May waste a bit of memory, but simplifies the interface
significantly.
Can't boot tonga with this (testing 4.14-wip)
Jul 28 23:00:29 ph4 kernel: [drm] amdgpu kernel modesetting enabled.
Jul 28 23:00:29 ph4 kernel: [drm] initializing kernel modesetting (TONGA
0x1002:0x6939
Andy Furniss wrote:
Bit late, but this causes a startup fail for me with r9 285 , nothing
logged, just a blank screen when the driver loads.
Heads of both amd-staging-4.11 and drm-next-4.14-wip both failing.
Both branches are OK now after the latest updates
Bit late, but this causes a startup fail for me with r9 285 , nothing
logged, just a blank screen when the driver loads.
Heads of both amd-staging-4.11 and drm-next-4.14-wip both failing.
Deucher, Alexander wrote:
-Original Message-
From: amd-gfx [mailto:amd-gfx-boun...@lists.freedeskt
Michel Dänzer wrote:
I'm pleased to announce the 1.3.0 release of xf86-video-amdgpu,
Highlights:
* Allow TearFree to be toggled at runtime via an RandR output property
"TearFree". The xorg.conf option "TearFree" now controls the default
value of the output properties.
Nice feature. Min
Zhu, Rex wrote:
Not set max fan speed in high performance level because of the fan noise.
Thanks, I tested the patch and all seems OK again.
Best Regards
Rex
From: amd-gfx on behalf of Zhu, Rex
Sent: Monday, February 6, 2017 10:09 PM
To: Andy Furniss
hmark that pegs
all the clocks high should also instantly force fan high?
I don't think that would be popular WRT noise.
Best Regards
Rex
-Original Message-----
From: Andy Furniss [mailto:adf.li...@gmail.com]
Sent: Wednesday, February 01, 2017 11:37 PM
To: Alex Deucher
Cc: Zhu, Re
Alex Deucher wrote:
On Tue, Jan 31, 2017 at 6:19 PM, Andy Furniss wrote:
Andy Furniss wrote:
Rex Zhu wrote:
in profiling mode, powerplay will fix power state
as stable as possible.and disable gfx cg and LBPW feature.
profile_standard: as a prerequisite, ensure power and thermal
Andy Furniss wrote:
Rex Zhu wrote:
in profiling mode, powerplay will fix power state
as stable as possible.and disable gfx cg and LBPW feature.
profile_standard: as a prerequisite, ensure power and thermal
sustainable, set clocks ratio as close to the highest clock
ratio as possible
Rex Zhu wrote:
in profiling mode, powerplay will fix power state
as stable as possible.and disable gfx cg and LBPW feature.
profile_standard: as a prerequisite, ensure power and thermal
sustainable, set clocks ratio as close to the highest clock
ratio as possible.
profile_min_sclk: fix mclk as p
e I tested.
Best Regards
Rex
-Original Message-----
From: Andy Furniss [mailto:adf.li...@gmail.com]
Sent: Monday, January 09, 2017 6:29 PM
To: Zhu, Rex; Alex Deucher
Cc: amd-gfx list
Subject: Re: [PATCH 4/4] drm/amd/powerplay: add profiling mode in dpm level
Hi, that change does fix it fo
_PROFILING)
amdgpu_set_clockgating_state(adev, AMD_IP_BLOCK_TYPE_GFX,
Zhu, Rex wrote:
Thanks Andy,
The attached patch can fix this bug.
Please review.
Best Regards
Rex
-Original Message-----
From: Andy Furniss [mailto:adf.li...@gmail.com]
Sent: Monday, January 09, 2017 4:18 AM
To: Al
Alex Deucher wrote:
On Fri, Dec 23, 2016 at 3:45 AM, Rex Zhu wrote:
Change-Id: I4a46440882cd94fe5e77e3f351aaccc218a2ece5
Patches 1-3:
Reviewed-by: Alex Deucher
patch 4:
Please add a better patch description and explain what profiling mode
is good for, etc.
This on drm-next-4.10-wip regres
Deucher, Alexander wrote:
-Original Message- From: amd-gfx
[mailto:amd-gfx-boun...@lists.freedesktop.org] On Behalf Of Andy
Furniss Sent: Sunday, November 06, 2016 3:31 PM To: Zhu, Rex;
Deucher, Alexander; amd-gfx@lists.freedesktop.org Subject: Re:
[PATCH] drm/amdgpu: set bypass mode
Zhu, Rex wrote:
Is there any harm in just always putting it into bypass mode or
does it interact badly with PG? Presumably it does (otherwise
we wouldn't need this patch), it would be good to note why.
Rex: when UVD PG enabled, DCLK/VCLK will be turn off when uvd is
idle(DCLK=OFF). If we set b
Alex Deucher wrote:
On Tue, Oct 11, 2016 at 7:48 PM, Andy Furniss wrote:
The boot vce/uvd issue is fixed in 4.9-wip now, so I can boot latest but -
The segfault on startx is still there.
Fixed in v2.
Yea, all OK now.
___
amd-gfx mailing list
Christian König wrote:
Andy & Leo could you give that a brief testing?
Seems to be OK for me.
I currently don't have a setup for encoding/transcoding clips.
Regards,
Christian.
Am 10.10.2016 um 18:45 schrieb Alex Deucher:
On Mon, Oct 10, 2016 at 9:40 AM, Christian König
wrote:
From: Chr
Grazvydas Ignotas wrote:
On Wed, Oct 12, 2016 at 2:48 AM, Andy Furniss wrote:
I still can't shutdown/reboot
as in https://bugs.freedesktop.org/show_bug.cgi?id=98200
which is fixed for radeon, but apparently not (for me at least) with amdgpu.
You probably need a951ed85abd46 that went t
ex Deucher
:04 04 a8f2ca9290985991b3cc37cbeb902f060573fdbb
2309b176a1d4ff9e59eaf25688b5db6eb9759dd0 M drivers
From: amd-gfx on behalf of StDenis, Tom
Sent: Tuesday, October 11, 2016 09:20
To: Andy Furniss; amd-gfx@lists.freedesktop.org
Cc: Deucher,
I can boot OK with this.
Christian König wrote:
From: Christian König
Add type, align_mask and nop to the physical mode VCE funcs as well.
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/vce_v3_0.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/amd/am
Christian König wrote:
From: Christian König
They are constant as well.
I die on driver load with this commit on R9285 testing on 4.9-wip.
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gf
patch.
Tom
From: amd-gfx on behalf of StDenis, Tom
Sent: Tuesday, October 11, 2016 08:11
To: Andy Furniss; amd-gfx@lists.freedesktop.org
Cc: Deucher, Alexander
Subject: Re: [PATCH 4/4] drm/amdgpu: used cached gca values for vi_read_register
Yup, my Tonga s
Alex Deucher wrote:
Using the cached values has less latency for bare metal and SR-IOV,
and prevents reading back bogus values if the engine is powergated.
I can't startx since this on r9285.
Seems there are further issues later in current 4.9-wip = I die on
driver load, will see if that's rel
With current drm-next-4.9-wip plus drm/amdgpu: fix addr handling in
amdgpu_vm_bo_update_mapping
testdma is now working OK for my R9285 - just did 35k tests while
simultaneously running valley/heaven, plus messing with
powerplay/cpufreq and all is
good, no lock, no vm faults.
Andy Furniss
Andy Furniss wrote:
This regresses vce perf badly on tonga
https://bugs.freedesktop.org/show_bug.cgi?id=97494
Maybe I need a better test case or faster cpu or something,
but vce powerplay encode issues disappeared for me with the latest
firmware.
I did eventually find an issue - but I don
Christian König wrote:
Am 22.09.2016 um 23:54 schrieb Andy Furniss:
Marek Olšák wrote:
This breaks Tonga such that it hangs. Reproducible quickly with:
R600_DEBUG=testdma glxgears
It's a randomized test that runs forever. It should hang within 2
seconds.
So what is the status of thi
Marek Olšák wrote:
This breaks Tonga such that it hangs. Reproducible quickly with:
R600_DEBUG=testdma glxgears
It's a randomized test that runs forever. It should hang within 2 seconds.
So what is the status of this now?
R600_DEBUG=testdma glxgears isn't a test I've run on my r9285 tonga
un
This has just gone into drm-next-4.9-wip and caused lots of logging noise.
Seems to work OK though.
Sep 14 23:18:38 ph4 kernel: [drm:gfx_v8_0_ring_emit_fence_gfx [amdgpu]]
*ERROR* amdgpu: writing more dwords to the ring than expected!
Sep 14 23:18:38 ph4 last message repeated 11 times
Sep 14 2
This regresses vce perf badly on tonga
https://bugs.freedesktop.org/show_bug.cgi?id=97494
Maybe I need a better test case or faster cpu or something,
but vce powerplay encode issues disappeared for me with the latest
firmware.
root wrote:
From: Rex Zhu
fix issue that encode test failed on th
37 matches
Mail list logo