EXA on R600 (AGP)

[PuckPoltergeist]

Is EXA available on R600 chips with AGP interface now? There was something on radeonhd ML, but how is the status now? Is there something where I can help to get it work, testing, error reports? I've tried it with actual git tree of radeonhd, but only got a black screen with

II) RADEONHD(0): Mapped IO @ 0xff3f0000 to 0x7ff84b449000 (size 0x00010000)
(II) RADEONHD(0): Mapped FB @ 0xd0000000 to 0x7ff837787000 (size 0x10000000)
(WW) RADEONHD(0): RHDCSInit: No CS for R600 and up yet.

this in the X-log.

[bridgman]

AGP support still needs some additional coding in the driver, mostly a bunch of new code in drm AFAIK. Alex is trying to get the EXA corruption issues worked out on PCIE first.

[PuckPoltergeist]

Tested the initial AGP support that got into r6xx-r7xx-support, but this results in a black screen when I start kdm (mouse is visible) and X consumes 100% CPU. :(

[bridgman]

OK, thanks. Could I ask you to post x log and dmesg output on pastebin or something ?

[PuckPoltergeist]

Since the logs normaly are to long to paste:

http://www.stud.tu-ilmenau.de/~johi-in/dmesg.rhd

http://www.stud.tu-ilmenau.de/~johi-in/Xorg.0.log.rhd

[agd5f]

In the meantime you can use the PCIE gart if you apply this patch to the rhd driver:
http://www.botchco.com/alex/xorg/force_pcie_mode.diff

[PuckPoltergeist]

In the meantime you can use the PCIE gart if you apply this patch to the rhd driver:
http://www.botchco.com/alex/xorg/force_pcie_mode.diff
Ok, I'll try. I've also tested Christians patches (http://lists.opensuse.org/radeonhd/2009-01/msg00350.html) but this led to screen corruptions. Will take a screenshot if it happens again.

[PuckPoltergeist]

Ok, I still get these screen corruptions:
http://www.stud.tu-ilmenau.de/~johi-in/Bildschirmfoto3.jpg

Also X didn't survived switching to console and back. After switching back, I got a black screen again with 100% CPU used by X.

This is from the first try:

[drm] Setting GART location based on new memory map
[drm] Loading RV635 CP Microcode
[drm] Loading RV635 PFP Microcode
[drm] Resetting GPU
[drm] writeback test succeeded in 2 usecs
[drm] writeback forced off
X:664 conflicting memory types d0000000-e0000000 write-combining<->uncached-minus
reserve_memtype failed 0xd0000000-0xe0000000, track write-combining, req write-combining
X:664 conflicting memory types d0000000-e0000000 write-combining<->uncached-minus
reserve_memtype failed 0xd0000000-0xe0000000, track write-combining, req write-combining
X:672 freeing invalid memtype d0000000-e0000000
[drm] Loading RV635 CP Microcode
[drm] Loading RV635 PFP Microcode
[drm] Resetting GPU


Second try I didn't switched to console but logged in to get the screenshot. After this, I removed radeon and drm kernel module and switched back to fglrx:

[fglrx] AGP detected, AgpState = 0x1f000b2b (hardware caps of chipset)
[fglrx] [agp] enabling AGP with mode=0x1f000b2a
agpgart-amd64 0000:00:00.0: AGP 3.0 bridge
agpgart-amd64 0000:00:00.0: putting AGP V3 device into 8x mode
fglrx_pci 0000:01:00.0: putting AGP V3 device into 8x mode
[fglrx] AGP enabled, AgpCommand = 0x1f000302 (selected caps)
[fglrx] Setup AGP aperture
[fglrx:__mc_heap_map_virtual_space] *ERROR* Failed to map the virtual space
[fglrx:mc_heap_alloc_reserved_mem] *ERROR* Can not get virtual address for this reserved range
[fglrx:MCIL_AllocateMemory] *ERROR* Can not allocate requested local FB memory
[fglrx:__gart_init] *ERROR* Gps_GartInitialization failed.
[fglrx:gal_init] *ERROR* Failed to initialize gal
[fglrx:mc_heap_init] *ERROR* Fail to initialize GAL
[fglrx:firegl_init_pcie] *ERROR* GAL initialization failure
X:5348 conflicting memory types d0000000-e0000000 uncached-minus<->write-combining
reserve_memtype failed 0xd0000000-0xe0000000, track uncached-minus, req uncached-minus
X:5348 conflicting memory types d0000000-e0000000 uncached-minus<->write-combining
reserve_memtype failed 0xd0000000-0xe0000000, track uncached-minus, req uncached-minus
X:5359 freeing invalid memtype d0000000-e0000000

[tball]

Ok, I still get these screen corruptions:
http://www.stud.tu-ilmenau.de/~johi-in/Bildschirmfoto3.jpg

Also X didn't survived switching to console and back. After switching back, I got a black screen again with 100% CPU used by X.

This is from the first try:


Second try I didn't switched to console but logged in to get the screenshot. After this, I removed radeon and drm kernel module and switched back to fglrx:

Those screen corruptions is not because of using AGP, but just the state of r600 support. I get the same corruptions on PCIE.

[bridgman]

FYI agd5f just pushed fixes for all the known corruption issues.

[agd5f]

Also AGP should work out of the box now.

[legume]

Also AGP should work out of the box now.

I just tried, had to add my pciid -

http://www.pastebin.ca/1329980

I get a writeback fail -


agpgart: Found an AGP 3.0 compliant device at 0000:00:00.0.
agpgart: Xorg tried to set rate=x12. Setting to AGP3 x8 mode.
agpgart: Putting AGP V3 device at 0000:00:00.0 into 8x mode
agpgart: Putting AGP V3 device at 0000:02:00.0 into 8x mode
[drm] Setting GART location based on new memory map
[drm] Can't use AGP base @0xe0000000, won't fit
[drm] Loading RV670 CP Microcode
[drm] Loading RV670 PFP Microcode
[drm] Resetting GPU
[drm] writeback test failed 0 deadbeef


This mobo is OK @ 8x with fglrx/smartgart & radeon (r500 card)

xorg log

http://www.pastebin.ca/1329985

[agd5f]

that's should be ok. Does r600_demo or accel work?

[legume]

that's should be ok. Does r600_demo or accel work?

No neither works -

bash-3.2# ./r600_demo t

*** ./r600_demo, version 6c5e578

VendorID: 1002 DeviceID: 9515
Chipset: RV670


* CP test: PACK0 scratch reg

***** CP: scratch: still not set after 1000000 loops: 0xdeadbeef, should be 0xcafebabe

* Current GPU state

***** FAILED

[legume]

No neither works -


Progress I've got it working now :-)

It's my old friend the BIOS setting AGP Aperture size.
128 = not working, 256 = working.

So writeback test now works as well as R600 demo.

As for exa and xv I am seeing the same as others have reported -

xv is eating alot of CPU and doing RGB colourspace instead of YUV (my R500 + radeon did it correctly, last time I tried)

exa on radeonhd just doesn't seem to do anything - it's just like "AccelMethod" "none" - much slower than frame buffer.

exa on radeon seems OK so far.

[bridgman]

if you're running the latest code it should be pretty fast; finally faster than shadowfb, I think. Can you pastebin a log ?

[legume]

if you're running the latest code it should be pretty fast; finally faster than shadowfb, I think. Can you pastebin a log ?

Sure -

http://www.pastebin.ca/1332723

xv is OK ish. Apart from the colour space issue both radeon and hd seem to have a slight accuracy problem compared to r500 xv / software. It could be that they are not using bilinear? (radeon bicubic should have been off as the test stream was not scaled)

[agd5f]

The colors are differences in the color conversion matrix. we probably need a better matrix. I added an xv attribute (XV_COLORSPACE) back in the overlay days for radeon to selection the colorspace (BT601 or 709 IIRC) for the conversion. We could probably do something similar for r6xx/r7xx.

[bridgman]

Last night on IRC I think we also reached the conclusion that we probably needed to stretch the range of values in the RGB output; most of the video standards seem to use something like 16..235 rather than 0..255.

This may explain why Xv seems a bit "washed out" compared to X11 -- my guess is that the player is doing the stretching when outputting to X11.

[legume]

The colors are differences in the color conversion matrix. we probably need a better matrix. I added an xv attribute (XV_COLORSPACE) back in the overlay days for radeon to selection the colorspace (BT601 or 709 IIRC) for the conversion. We could probably do something similar for r6xx/r7xx.

That will be cool :-)

Apart from the colour space, r600 xv is also softening things somewhat - I assume it's not doing bilinear like r500 did for unscaled images.

Here are a couple of xwds converted to png of a paused frame with x11/xv.

The frames are not scaled at all, for me viewing on a CRT @ 1024x768 the xv is too soft. I don't know what they will look like for people with highres/scaled LCDs.

www.andyqos.ukfsn.org/r600-x11-flw.png
www.andyqos.ukfsn.org/r600-xv-flw.png

[bridgman]

Sure -

http://www.pastebin.ca/1332723

xv is OK ish. Apart from the colour space issue both radeon and hd seem to have a slight accuracy problem compared to r500 xv / software. It could be that they are not using bilinear? (radeon bicubic should have been off as the test stream was not scaled)

Bingo. Your code is from commit 1332723, which is four days old and therefore totally obsolete :D

The performance optimizations went in after you pulled the source code. Time to pick up the latest tree.

I hadn`t heard of any differences in Xv between 5xx and the latest code but I imagine that`s because nobody has compared them. We`ll start asking and see what feedback we get. The 5xx code did YUV-to-RGB conversion in the texture hardware while 6xx and 7xx do it in shader code, so there may be some differences that need to be tweaked.

Our current thinking is that what everyone calls YUV is probably really Y`CbCr, which is different in a variety of subtle ways, but that`s nothing specific to 6xx and 7xx.

[agd5f]

That will be cool :-)

Apart from the colour space, r600 xv is also softening things somewhat - I assume it's not doing bilinear like r500 did for unscaled images.


Neither driver filters unscaled images. When scaling, r6xx only supports bilinear filtering right now, bicubic hasn't been implemented yet.

[bridgman]

Apart from the colour space, r600 xv is also softening things somewhat

Thanks for the pics. It really does look like Xv is filtered more, doesn`t it. Some of that can be explained by the compressed dynamic range (higher contrast images usually seem sharper) but I have a tough time believing that the contrast stretch will account for all the differences.

I guess it`s possible the texture engine is doing some filtering we aren`t expecting (it`s only got about a million options ;)) but as agd5f said the code is not trying to do any filtering. We probably won`t know for sure until the contrast stretch goes in first and we look at updated images.

EDIT - I do have to say that the X11 pic seems to have its contrast OVER-stretched, to the point that some of the higher brightness info is getting clipped away.

[legume]

Bingo. Your code is from commit 1332723, which is four days old and therefore totally obsolete :D


Doh - I thought I was up to date, I guess I forgot to switch branches when I looked on the web interface. Thanks for looking.

[bridgman]

I don't think you forgot to switch branches. The cgit web interface was acting up over the last few days - it was missing recent changes on a regular basis. New code was pushed yesterday which seems to have fixed the problems :

http://www.clearchain.com/blog/posts/cgit-bug-fixes-tagbranch-support-in-logs

[agd5f]

When in doubt run 'git fetch' to grab the latest remote branches. You can then pull those changes into your local tree.

[legume]

Thanks for the pics. It really does look like Xv is filtered more, doesn`t it. Some of that can be explained by the compressed dynamic range (higher contrast images usually seem sharper) but I have a tough time believing that the contrast stretch will account for all the differences.

I guess it`s possible the texture engine is doing some filtering we aren`t expecting (it`s only got about a million options ;)) but as agd5f said the code is not trying to do any filtering. We probably won`t know for sure until the contrast stretch goes in first and we look at updated images.

EDIT - I do have to say that the X11 pic seems to have its contrast OVER-stretched, to the point that some of the higher brightness info is getting clipped away.

Yea I noticed the crane had bits missing, but then thought the bits that are missing are quite dark, so shouldn't really be stretched up to white. Perhaps because xv seems to be sampling vertically as well as horizontally the detail survived better than X11 software/mmx conversion.

I made a couple more with a different stream - one I used a lot on r500 to test vsync so I know that on r500 the xv looked like x11 in that the interlacing artifacts are painfully obvious and distinct, unlike r600 where they are filtered somewhat.

www.andyqos.ukfsn.org/r600-xv.png
www.andyqos.ukfsn.org/r600-x11.png

from 11meg bbc3_060.m2v test stream here -

ftp://ftp.tek.com/tv/test/streams/Element/MPEG-Video/625/

[bridgman]

Alex just pushed a change to radeonhd (written by yangman) which stretches the dynamic range of the decoded RGB from 16..235 to 0..255, making it match the X11 output. Might be worth pulling the new code and seeing how much of the visible difference was related to contrast (since that should be gone now) and how much apparent filtering remains.

FYI there is a discussion on #radeonhd right now about the results; Zajec posted a couple of pics which definitely show some filtering on the Xv output even after the contrast difference has been eliminated.

[PuckPoltergeist]

Alex just pushed a change to radeonhd (written by yangman) which stretches the dynamic range of the decoded RGB from 16..235 to 0..255. Might be worth pulling the new code and seeing how much of the visible difference was related to contrast (since that should be gone now) and how much apparent filtering remains.

FYI there is a discussion on #radeonhd right now about the results; Zajec posted a couple of pics which definitely seem to show some filtering remaining after the contrast difference is resolved.

I'm testing it this moment. Still (or again) getting some screen corruptions. Will upload a screenshot as soon as possible.

PS: Changing back from console to X still leads to a black screen with no response on any input. Last entry in the X-log is

(II) RADEONHD(0): [agp] Mode 0x1f000b2b [AGP 0x1022/0x7454]

PPS: schreenshot is here: http://www.stud.tu-ilmenau.de/~johi-in/Bildschirmfoto5.jpg
Corruptions are visible at the buttons at the top of the window.

[legume]

FYI there is a discussion on #radeonhd right now about the results; Zajec posted a couple of pics which definitely show some filtering on the Xv output even after the contrast difference has been eliminated.

Thanks for the info - I was just doing some new ones myself which show xv is still softer - but you were right about the loss of detail on the crane being colour related on this particular stream :-)

www.andyqos.ukfsn.org/new-x11-flw.png
www.andyqos.ukfsn.org/new-xv-flw.png