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
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
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
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)
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)
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
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
? 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
在 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
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? ??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日 上午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
? 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
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
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
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
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
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
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
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
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
Regards,
-- Chen Jie
Regards,
-- Chen Jie
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
> 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 :
> &
.
> 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 :
> &
.
> 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
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?
>
>
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?
>
>
31 matches
Mail list logo
