AM is mapped to an uncached area in out platform, so, my
question is what could go wrong while using >4B load/store
instructions in UVD workflow? Any idea?
-- Regards,
Chen Jie
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lis
me and GPU reset time.
> Whether GPU reset happens, the "ring test" at system resume time is always
> successful. But the "ring test" at GPU reset time usually fails.
>
> We use the latest kernel (3.1.0-RC8 from git) and X.org is 7.6.
>
> Any ideas?
>
>
.
> This is only applies to the old rage128/r1xx gart block on
> early radeon asics (~r1xx-r4xx). Newer PCI and IGP cards
> can handle 40 bits just fine.
>
> Signed-off-by: Alex Deucher
> Cc: Chen Jie
> ---
> drivers/gpu/drm/radeon/radeon_device.c |7 ---
> 1 f
> devices.
>
> Does fence_wait depends on GPU's interrupt? If yes, then can I say "GPU
lockup" is caused by unexpected disabling of GPU's irq?
> > Hi Alex, Michel
> >
> > 2011/10/5 Alex Deucher
> >
> >> 2011/10/5 Michel D鋘zer :
> &
Regards,
-- Chen Jie
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
2011/11/5 Alex Deucher :
> On Fri, Nov 4, 2011 at 10:26 AM, Chen Jie wrote:
>> Hi all,
>>
>> I tried to create/pin ring BO in VRAM instead of GTT to debug some
>> ring-related problems. After I did this, it rendered a black screen in
>> X (on a X86 RS780E board
Hi,
Some status update.
在 2011年9月29日 下午5:17，Chen Jie 写道：
> Hi,
> Add more information.
> We got occasionally "GPU lockup" after resuming from suspend(on mipsel
> platform with a mips64 compatible CPU and rs780e, the kernel is 3.1.0-rc8
> 64bit). Related kernel mess
BTW, how does the dummy page work in GART?
Regards,
-- Chen Jie
在 2011年12月7日 下午10:21，Alex Deucher 写道：
> 2011/12/7 :
>> When "MC timeout" happens at GPU reset, we found the 12th and 13th
>> bits of R_000E50_SRBM_STATUS is 1. From kernel code we found these
>> two b
system memory address(bus address) of ring_obj to an
arbitrary value, e.g. 0 or 128M.
2. Changes the system memory address of a BO in radeon_test to an
arbitrary value, e.g. 0
Non of above leaded to a GPU Lockup:
Point 1 rendered a black screen;
Point
在 2012年2月16日 下午5:21，Chen Jie 写道：
> Hi,
>
> 在 2012年2月15日 下午11:53，Jerome Glisse 写道：
>> To me it looks like the CP is trying to fetch memory but the
>> GPU memory controller fail to fullfill cp request. Did you
>> check the PCI configuration before & after (when thin
在 2012年2月17日 上午12:32，Jerome Glisse 写道：
> Ok let's start from the begining, i convince it's related to GPU
> memory controller failing to full fill some request that hit system
> memory. So in another mail you wrote :
>
>> BTW, I found radeon_gart_bind() will call pci_map_page(), it hooks
>> to swi
ils to feed CP
when lockup? May a former SURFACE_SYNC block the MC?
P.S. We hack to place CP ring, ib and ih at vram and disable
wb(radeon_no_wb=1) in today's debugging.
Any idea?
Regards,
-- Chen Jie
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
在 2012年2月17日 下午5:27，Chen Jie 写道：
>> One good way to test gart is to go over GPU gart table and write a
>> dword using the GPU at end of each page something like 0xCAFEDEAD
>> or somevalue that is unlikely to be already set. And then go over
>> all the page and chec
dwords in CP ring -- with 319 CP_PACKET2 and 0xc0033d00
in the end.
Are these normal?
BTW, is there any way for X to switch to NOACCEL mode when the problem
happens? Thus users will have a chance to save their documents and
then reboot machine.
Regards,
-- Chen Jie
he CPU usage is around 50%, and all three
video samples play well on X86 platform with the same video card.
BTW, 785G also has UVD2.0, is it supported currently? Or will it be
supported in the near future?
Regards,
Chen Jie
[1] http://www.lemote.com/products/computer/fulong/348.html (zh_CN)
.
> This is only applies to the old rage128/r1xx gart block on
> early radeon asics (~r1xx-r4xx). Newer PCI and IGP cards
> can handle 40 bits just fine.
>
> Signed-off-by: Alex Deucher
> Cc: Chen Jie
> ---
> drivers/gpu/drm/radeon/radeon_device.c |7 ---
> 1 f
> devices.
>
> Does fence_wait depends on GPU's interrupt? If yes, then can I say "GPU
lockup" is caused by unexpected disabling of GPU's irq?
> > Hi Alex, Michel
> >
> > 2011/10/5 Alex Deucher
> >
> >> 2011/10/5 Michel D?zer :
> &
me and GPU reset time.
> Whether GPU reset happens, the "ring test" at system resume time is always
> successful. But the "ring test" at GPU reset time usually fails.
>
> We use the latest kernel (3.1.0-RC8 from git) and X.org is 7.6.
>
> Any ideas?
>
>
BTW, how does the dummy page work in GART?
Regards,
-- Chen Jie
? 2011?12?7? ??10:21?Alex Deucher ???
> 2011/12/7 :
>> When "MC timeout" happens at GPU reset, we found the 12th and 13th
>> bits of R_000E50_SRBM_STATUS is 1. From kernel code we found these
>> two b
system memory address(bus address) of ring_obj to an
arbitrary value, e.g. 0 or 128M.
2. Changes the system memory address of a BO in radeon_test to an
arbitrary value, e.g. 0
Non of above leaded to a GPU Lockup:
Point 1 rendered a black screen;
Point 2 only the test itself failed
Any idea?
Regards,
-- Chen Jie
? 2012?2?16? ??5:21?Chen Jie ???
> Hi,
>
> ? 2012?2?15? ??11:53?Jerome Glisse ???
>> To me it looks like the CP is trying to fetch memory but the
>> GPU memory controller fail to fullfill cp request. Did you
>> check the PCI configuration before & after (when thin
? 2012?2?17? ??12:32?Jerome Glisse ???
> Ok let's start from the begining, i convince it's related to GPU
> memory controller failing to full fill some request that hit system
> memory. So in another mail you wrote :
>
>> BTW, I found radeon_gart_bind() will call pci_map_page(), it hooks
>> to swi
ils to feed CP
when lockup? May a former SURFACE_SYNC block the MC?
P.S. We hack to place CP ring, ib and ih at vram and disable
wb(radeon_no_wb=1) in today's debugging.
Any idea?
Regards,
-- Chen Jie
? 2012?2?17? ??5:27?Chen Jie ???
>> One good way to test gart is to go over GPU gart table and write a
>> dword using the GPU at end of each page something like 0xCAFEDEAD
>> or somevalue that is unlikely to be already set. And then go over
>> all the page and chec
dwords in CP ring -- with 319 CP_PACKET2 and 0xc0033d00
in the end.
Are these normal?
BTW, is there any way for X to switch to NOACCEL mode when the problem
happens? Thus users will have a chance to save their documents and
then reboot machine.
Regards,
-- Chen Jie
Regards,
-- Chen Jie
2011/11/5 Alex Deucher :
> On Fri, Nov 4, 2011 at 10:26 AM, Chen Jie wrote:
>> Hi all,
>>
>> I tried to create/pin ring BO in VRAM instead of GTT to debug some
>> ring-related problems. After I did this, it rendered a black screen in
>> X (on a X86 RS780E board
Hi,
Some status update.
? 2011?9?29? ??5:17?Chen Jie ???
> Hi,
> Add more information.
> We got occasionally "GPU lockup" after resuming from suspend(on mipsel
> platform with a mips64 compatible CPU and rs780e, the kernel is 3.1.0-rc8
> 64bit). Related kernel mess
he CPU usage is around 50%, and all three
video samples play well on X86 platform with the same video card.
BTW, 785G also has UVD2.0, is it supported currently? Or will it be
supported in the near future?
Regards,
Chen Jie
[1] http://www.lemote.com/products/computer/fulong/348.html (zh_CN)
use that
chip :)
So it will improve HD video playback experience on that platform.
Regards,
Chen Jie
[1] http://en.wikipedia.org/wiki/Loongson#Loongson_3
2014/1/10 Mike Lothian :
> Fingers crossed this happens soon especially now that BluRays can be played
> on Linux
>
> 1080p VC1 does not play well on a Phenom II X4 even when multi threaded
It seems UVD based VC1 playback is broken??
With a Radeon 6570 card, neither X86 nor the loongson platform g
31 matches
Mail list logo
