pbdl: hello everyone
pbdl: can anyone help me with xrandr? i don't know if i found a bug in radeon driver or not
pbdl: it doesn't detect S-video
airlied: pbdl: you may need to force it on, we don't always autodetect s-video properly
airlied: xrandr --output S-video --set load_detection 1
airlied: pbdl: might help
pbdl: see here the complete output of xrandr - http://paste.debian.net/14800/ . just in case i wasnt clear (S-video doesn't show at all)
airlied: pbdl: ah its it an r500?
pbdl: http://paste.debian.net/14806/ your suggestion
airlied: we turned it off until we can get it working properly
airlied: the later cards we had to disable it as it doesn't work right yet
pbdl: r500? i thought it was r300 (noob here hello :) )
pbdl: its mobility radeon x700
airlied: can you pastebin /var/log/Xorg.0.log
airlied: pbdl: ah maybe its got a bad BIOS then
pbdl: mm
pbdl: hold on, im going for that log
pbdl: i cant even find the begginning of it with cat :P
pbdl: http://paste.debian.net/14807/
pbdl: hope it helps, im NOT putting fglrx :)
airlied: pbdl: hmm we skip tv out on atombios.. I wonder should we leave it for r400s..
airlied: pbdl: did you install the driver yourself from source?
agd5f: I don't hink anyon'e gotten r4xx workig yet
pbdl: can you explain what is atombios? bios from toshiba is phoenix
airlied: agd5f: oh it it different to r300
airlied: ?
pbdl: is it the ati bios?
agd5f: controller is the same, but there's gpio magic needed to toggle between vga and tv
airlied: agd5f: ah .. damn gpio magics.
pbdl: if theres something i can do to help
agd5f: pbdl: https://bugs.freedesktop.org/show_bug.cgi?id=12007#c35
agd5f: I was hoping we could use atombios, and maybe we still can, but I haven't had time to dig further in quite a while
pbdl: ok. in Debian how do i stop x from booting, and revert back? i'll probably find the answer, but can take time.
agd5f: pbdl: start in single user mode (recovery or safe option in grub)
pbdl: AH rgr that
pbdl: found a problem downloading radeondump
pbdl: "not found"
agd5f: pbdl: you need to use git
agd5f: pbdl: apt-get install git-core; git clone git://people.freedesktop.org/~glisse/radeondump
pbdl: and then the patch?
agd5f: wget http://www.botchco.com/alex/xorg/fixpll_radeondump.diff
agd5f: cd radeondump; patch -p1 -i fixpll_radeondump.diff
pbdl: no no, heh, applying it
pbdl: ty
agd5f: :)
pbdl: cant find vbetest
pbdl: something elsei can use in the repo?
agd5f: pbdl: http://people.freedesktop.org/~airlied/xresprobe-mjg59-0.4.21.tar.gz
agd5f: or http://www.srcf.ucam.org/~mjg59/vbetool/
pbdl: i forgot, this is a new install. what utils i need to compile?
agd5f: pbdl: gcc and make at least
pbdl: i have both. why do i get - ./configure: No such file or directory -
agd5f: I think you need cmake for radeondump
agd5f: and libpciaccess
pbdl: -dev or 0 ? dev right?
agd5f: yeah
pbdl: still get that error. theres something terribly dumb im doing
agd5f: pbdl: what error?
agd5f: cmake .
pbdl: trying to ./configure
pbdl: or thats not how i do it?
agd5f: nope. it uses cmake. so run 'cmake .'
pbdl: cmake . just dumpls the help
pbdl: *dumps
agd5f: pbdl: are you running it in the directory where you downloaded radeondump?
pbdl: no, for vbetest app
pbdl: in that folder, after extracting
pbdl: ah wait, im really exausted
pbdl: i need sleep
pbdl: cmake . tells me theres isnt any CMakeLists.txt
agd5f: just radeondump uses cmake
agd5f: I think you can just run make for vbetest
pbdl: ok.
agd5f: I need to head to bed myself
pbdl: ah hold. i need to compile it while in tv-out only right'
agd5f: you can comple it whenever
pbdl: *** No rule to make target `/usr/lib/gcc/x86_64-linux-gnu/4.0.3/include/stddef.h', needed by `vesamode.o'. Stop.
pbdl: :/ wow
agd5f: what you want to do is use vbetest to set an 800x600 mode and then dump the regs with radeondump
agd5f: pbdl: are you on 32 bit?
pbdl: indeed, but i need the vbetest compiled. yes 32 bit
pbdl: ill figure it out tomorrow. with time i can google and learn heh
pbdl: do i come back here'
pbdl: t?
agd5f: IIRC, there was some trick, but I haven't built it in a while. I think you have to change the Makefile for 32 bit. airlied may remember better
agd5f: pbdl: I'll be here :)
pbdl: ty, i hope i can help you guys!
pbdl: tand help myself in the process
pbdl: whats with the t's already :P
pbdl: need sleep!
pbdl: ty for the help. now i know its the driver, and maybe i can help. see you tomorrow
agd5f: pbdl: see ya
mikkoc: just read about dynamic clocks: http://www.phoronix.com/scan.php?page=news_item&px=NjQxNw
mikkoc: but i cant find the commit in master
mo0n_sniper: where can i find a ppa for mesa with the fix for rs4xx to make compiz work?
mo0n_sniper: or a deb for ubuntu
mlankhorst: http://tinyurl.com/2j6bh
adamk: lol
mo0n_sniper: ok thanks
adamk: I'm not even sure there is one.
mo0n_sniper: there is but i can't find it anymore
mo0n_sniper: and with people like mlankhorst ....it even harder
mo0n_sniper: *it's
ssam: mo0n_sniper, search for xontheedge i think thats the name of the wiki page
mo0n_sniper: xontheedge point me to https://launchpad.net/~stikonas/+archive but that's for interpid and i have hardy
ssam: https://wiki.ubuntu.com/XorgOnTheEdge
stikonas: mo0n_sniper: packages are for hardy, intrepid does not need any patches
mo0n_sniper: how do i upgrade just mesa?
stikonas: add deb http://ppa.launchpad.net/stikonas/ubuntu hardy main to /etc/apt/sources.list
stikonas: and then just do upgrade
mo0n_sniper: I don't whant to upgrade with all the packages there (some are verry unstable) i just whant to upgrade mesa and dependencies
stikonas: add deb http://ppa.launchpad.net/stikonas/ubuntu hardy main to /etc/apt/sources.list
stikonas: ant update mesa packages
mo0n_sniper: sudo apt-get install mesa will do?
stikonas: I think it will
stikonas: and be sure to remove sources that may have unstable mesa such as repository from XorgOnTheEdge
mo0n_sniper: thanks that was what i needed
mo0n_sniper: and i think i used your ppa before
osiris_: mmp: just sent you another patch for X radeon driver
mmp: osiris_: ok, thanks, will try in a minute :)
mmp: (or two, maybe I'll first grab something to eat:)
mmp: osiris__away: going to give it a try
mmp: osiris_: I just tested it, but I see no debug output in logfile...
mmp: isn't there something more I have to enable?
osiris_: no
osiris_: could you post it?
mmp: ok, just a sec...
osiris_: mmp: oh, I can see the problem now
mmp: and I'm blind to not see the register writes:)
mmp: I probably didn't write the search regexp correctly :)
mmp: hmm, FB_LOCATION both being zero ?
mmp: *both values
mmp: but that's just uneducated guess :)
osiris_: mmp: look for [W] and [R]
osiris_: yeah, but the problem is that I wrongly programm these regs
mmp: osiris_: I'll be here for a while, in case you would need to test something :)
osiris_: mmp: yeah, I will send you new patch in few minutes
osiris_: mmp: new patch for radeon X driver: http://pastebin.com/m263ea2c2
osiris_: try it with dri disabled
osiris_: mmp: oops, there was a type in previous one. check this one: http://pastebin.com/m10996c25
mmp: osiris_: just up to the time, I was just about to reboot :)
osiris_: mmp: you don't have to reboot to try new patches for radeon X driver
osiris_: mmp: just make sure that drm modules doesn't get loaded
mmp: hmm, I thought that having clean (i.e. not affected by running fglrx) state could help...
mmp: ok, going to give it a try :)
osiris_: mmp: oh I forgot you're using fglrx.
osiris_: yeah, in that case reboot is helpful
mmp: osiris_: anyway, it looks like without reboot the driver initializes properly
mmp: at least, it did not hang :)
osiris_: mmp: great, then try with reboot
mmp: and I was able to move mouse etc.
mmp: ok :-)
mmp: osiris_: works
mmp: even after cold reboot
osiris_: mmp: :) post Xorg log somewhere
osiris_: mmp: is VT switching working?
mmp: let me see...
mmp: yes, at least with just bare X server running
osiris_: mmp: good. here's new patch for drm: http://pastebin.com/m645afdd4
osiris_: remember to add pci id
osiris_: set only one option for now: RADEON_NEW_MEMMAP
osiris_: and set debug option for drm module :)
mmp: ok, but it will take a while; last time I had some failed hunks I had to solve...
mmp: ok :)
mmp: I guess I should remount to sync again :)
osiris_: mmp: yeah
mmp: osiris_: I've seen just black screen
mmp: but in kernel logs you can find maybe something userful; last messages were written periodically to log...
osiris_: mmp: promising :)
osiris_: add RADEON_IS_IGPGART option to your pci id
mmp: ok...
mmp: going to try it
mmp: osiris_: roughly the same...
osiris_: mmp: does it hang the machine?
mmp: osiris_: not exactly, kernel runs fine, and apparently also userspace (metalog output being written)
mmp: just the screen is black
mmp: I did not attempt to kill X server using ctrl-alt-bksp, though
osiris_: mmp: can you return to text mode by VT switching or X kill?
mmp: wait for a second, I'll see
mmp: osiris_: switching doesn't work
mmp: neither killing
mmp: moreover, I'm not able to reboot machine using magic sysrq sequence...
mmp: or at least I hope it's it
mmp: but I don't see pressing it in logs, so either it directly reboots and doesn't print anything, or I'm just pressing bad key combo (magic and B-key)
osiris_: mmp: new patch for drm
mlankhorst: Just wondering http://www.x.org/docs/AMD/r600isa.pdf is that sufficient for r6xx 3d?
mlankhorst: Oh nm, only describes the instruction set.
mmp: osiris_: ok, going to check mail, I just ran away for a while
osiris_: mmp: oh, didn't post url :P http://pastebin.com/m21613d18
blathijs: Should it be possible for a program to cause an assert in mesa (the r300 dri driver in particular)? Or does an assert always mean a mesa bug?
mmp: osiris_: btw, should I use IGPGART, or again leave just the memory thing? :)
osiris_: leave it enabled
mmp: assumes 'it' stands for IGPGART
osiris_: yes
mmp: osiris_: the same...
mmp: although it looks like AGP location is different this time
osiris_: mmp: could you make mmio trace of it?
mmp: ugh, I'm not sure...
mmp: I'm running 2.6.26 kernel
mmp: I have 2.6.27-rc3 here, which already contains mmio module...
mmp: maybe I could try to patch that one
mmp: aiee, looks like patching of 2.6.27 fails...
osiris_: mmp: here's new patch with some added debug info: http://pastebin.com/d1d1770a
osiris_: mmp: to reduce number of reboots try running it like this: modprobe radeon; X & (sleep 5 && killall -9 X && vbetool post)
osiris_: of course check if you have vbetool installed :)
mmp: osiris_: vbetool is not that much good idea
mmp: it leaves console in state where just nothing is visible
mmp: even now I had to start X server in order to write somethin...
mmp: and even vt switching doesn't seem to help..
osiris_: mmp: wait one moment, I will add some more debuging info
mmp: but reboots aren't basically that bad, BIOS POST is quite quick :)
mmp: ok
mmp: in the meanwhile I'll reboot to get my console back :)
mmp: back :)
osiris_: mmp: http://pastebin.com/d3ca8af73
mmp: osiris_: ok, going to compile && try
mmp: osiris_: I hope the logs are complete, metalog decided (in the middle of kernel log) that it would be a nice idea to split logfile
osiris_: airlied/agd5f/glisse: I have a question about gart. gart table be placed in vram, right?
osiris_: mmp: now remove all code from radeon_setup_rs600_mc func and try again
agd5f: osiris_: depends. pcie page table is in vram, igp/pci/agp is in system memory
osiris_: mmp: now without any logs, just want to know if it will hang
osiris_: agd5f: then looks like rs600 gart pcie gart, because it is always placed at the end of framebuffer
osiris_: *rs600 has
osiris_: mmp: remove RADEON_IS_IGPGART from your pci id
mmp: done
mmp: btw, shouldn't I also add RADEON_IS_IGP? (asking just in case..
mmp: )
osiris_: mmp: nope
mmp: ok :)
osiris_: have you already removed code from setup_rs600_mc?
mmp: just added return ; as the first line of code
mmp: is too lazy to delete code :)
osiris_: mmp: then revert it. change of plans :) try current code without RADEON_IS_IGPGART option
osiris_: with logs
mmp: ok
mmp: osiris_: I'll go away for a while, will be back in ~10 minutes
mmp: I just have to grab something to eat
mmp: :)
osiris_: ok
osiris_: agd5f: is gart table address held in dev_priv->gart_info.bus_addr?
pbdl: hello
pbdl: im trying to figure out how to use vbetool for this purpose - https://bugs.freedesktop.org/show_bug.cgi?id=12007#c35 - but i cant figure it out. the man page leaves me in the dark im afraid.
mmp: osiris_: back
pbdl: and vbetest wont compile (im on 32 bit)
pbdl: i appreciate any help. tia
pbdl: agd5f, are you around?
agd5f: osiris_: yes
agd5f: pbdl: sort of. on a conf call
pbdl: oh
osiris__: agd5f: then something is going wrong. fb is 0x70000000 - 0x7ffffff, and gart table addr is 0x61BB0000 and that is certainly outside fb area
pbdl: agd5f: ill be back later then. xchat stays connected just in case.
osiris__: agd5f: is there any other option that one have to set to enforce pcie gart table (other than not enabling RADEON_IS_IGPGART in pci id)?
mmp: osiris__: quick grepping found something like RADEON_IS_PCIE
mmp: checked against dev_priv->flags
agd5f: osiris__: pcie takes an MC address. you have to make sure the RADEON_IS_PCIE flag is set
osiris__: osiris: yeap, searching now where RADEON_IS_PCIE is set
osiris__: lol
osiris__: *mmp:
mmp: :-))
mmp: agd5f if the flag is not set automagically, then it is not...
agd5f: mmp: IIRC, the ddx sets it
agd5f: mmp: you could force it on though in teh drm
agd5f: however, the rs600 doesn't have the same pcie regs as r3xx-r5xx
osiris__: nope, it's read from capability list
mmp: aiee...
mmp: in the logs, radeon driver says something like PCI card detected...
mmp: and according to radeon_cp:1820 ...
agd5f: I suspect we'll need a separate path for rs600 gart setup anyway so you could use the chipfamily
mmp: it should print something else right now...
agd5f: osiris__: also, if the pt has to be in vram, then you'll need to allocate the space in the ddx like for pcie cards
mmp: hmm, it's still intereting why drm_device_is_pcie(dev) returns false...
agd5f: mmp: the device isn't really pcie
agd5f: it's it's own thing
osiris__: mmp: patch for radeon ddx http://pastebin.com/d25e3a112
mmp: agd5f: what is it then? if it is really on pcie bus, then it should expose it in PCI capabilities...
osiris__: agd5f: maybe there is a register which tells us which gart type the card use?
osiris__: agd5f: maybe GART_FEATURE_ID.REV_ID?
agd5f: osiris__: it's family specific
osiris__: aha
agd5f: discrete cards are generally easier since they use a common bus
agd5f: IGP cards are part of the northbridge so they tend to have architexture specific quirks
osiris__: agd5f: why is the ddx driver responsible for allocating gart table?
agd5f: osiris__: becasue it slices up the framebuffer
mmp: I always thought that even integrated devices are connected to some standard bus, as PCI/AGP/PCIE..
mmp: going to try the patch..
osiris__: ok
agd5f: osiris__: kernel modesetting moves all the buffer management to the kernel
osiris__: mmp: wait
osiris__: agd5f: too bad that kms isn't going to be widely used for more than 6 months :/
agd5f: osiris__: yeah
mmp: osiris__: too late...
mmp: it did the same as before :)
osiris__: mmp: any logs?
mmp: yes, preparing them
osiris__: ok
mmp: osiris__: btw, why did I have to wait?
osiris__: mmp: because that patch was only partial fix
mmp: or, better said, "had" (I hope I chose proper tense)
osiris__: mmp: that should be the good one: http://pastebin.com/d5bf7e218
pbdl: agd5f: im the same pbdl from yesterday - https://bugs.freedesktop.org/show_bug.cgi?id=12007#c35 . i found lrmi sourceforge page which has vbetest - hopefully it's the same thing. it compiled ok
pbdl: do i just run 'vbetest' then choose 290? then run radeondump?
pbdl: going for it if i got it straight
pbdl: my main doubt is the "tv-out active" part.. *pbdl places head back in the sand*
mmp: osiris_: again the same behavior
blathijs: Is there any way to force mesa to do software rendering and not using the dri hardware driver?
jcristau: blathijs: disable aiglx, and set LIBGL_ALWAYS_INDIRECT
blathijs: Wow, that's really completely slow :-)
osiris_: blathijs: LIBGL_ALWAYS_SOFTWARE with recent mesa
osiris_: mmp: I'm currently out of ideas
osiris_: mmp: what exactly is happening on screen?
mmp: osiris_: it just turns black, now I'm not sure whether the backlight is also turned off...
mmp: btw, is it OK that drm module still uses this card as PCI?
blathijs: Hmm, that didn't really help, the game still quits with "Error: R300 timed out... exiting"
osiris_: mmp: it shouldn't cause any problems
blathijs: and then hangs my console and X server...
mmp: osiris_: I just grepping and there is e.g. setup of pcie gart... but I'm just guessing...
mmp: I don't have exact idea how do these things work
osiris_: agd5f: maybe you have some ideas. here's the filtered mmio trace: http://pastebin.com/d6b08f742. current radeon ddx and drm patches: http://pastebin.com/d3ca8af73 http://pastebin.com/d5bf7e218
osiris_: mmp: if pcie gart is invoked depends on radeon X driver
blathijs: osiris_: Ah, your env variable seems to work. ALWAYS_INDIRECT made glxgears superslow, but still crashed the game.
mmp: osiris_: there are many places where it also depends on RADEON_IS_PCIE
blathijs: What exactly does Indirect mean? Apparently it still uses my hardware-specific driver, but not with DRI or something?
osiris_: blathijs: IIRC it means that all gl calls are packed in glx protocol
blathijs: osiris_: So the same operations will still end up at the hardware, just not as fast. That would mean the DRI is not the problem, but the r300 gl stuff (not sure how this architecture works completely...)
blathijs: eboettcher: I found a log saying you were experiencing the samen error I'm having a few months ago ("Error: R300 timed out... exiting"). Did you solve that? Are you using an Xpress 200 as well, by any chance?
osiris_: blathijs: currently not all gl extensions are exported through glx (so they aren't available with indirect rendering)
blathijs: osiris_: Ah, but since direct or indirect doesn't make a difference for me (both crash), it seems that that's not the problem
mmp: osiris_: Just for the completeness I did also test with card type forced to PCIE, but it doesn't seem to help...
mmp: I just wonder why drm_ati_pcigart_init is still called, instead of pciegart variant
osiris_: mmp: there's no seperate drm_ati_pciegart_init variant
osiris_: the drm_ati_pcigart_init func has necessery paths
mmp: osiris_: aha, ok... when the halluciation starts, it's time to get a pause :)
osiris_: :)
mmp: osiris_: if you had any idea, just send me an email, I will try to reply as soon as possible...
mmp: as of sunday I will be a bit away (probably even from internet connection), so the communication will be more difficult.
osiris_: mmp: ok, maybe agd5f, glisse or airlied will figure it out
mmp: (and I will be also quite busy)
osiris_: mmp: I'll be away too
mmp: I hope someone will come with some idea, we are probably that close...
osiris_: mmp: actually we may be pretty far away. RE is pretty unpredictable. I was REing RS690 for more than 2 months (but I was just starting developing back then) and without other devs help I wouldn't have made it
blathijs: Hah, disabling a bunch of graphics related options makes the game run on a whipping 25FPS :-)
mmp: osiris_: :-) I know such feelings; but also the feeling whnen something doesn't work, you try to fix it...
mmp: and then someone comes and simply says "enable this bit and it will work"
blathijs: osiris_: What's REing?
mmp: you do that, and it will work :)
mmp: blathijs: reverse engineering
osiris_: mmp: exactly :)
mmp: osiris_: btw, I thought the documentation is already freely available...
osiris_: mmp: it wasn't when I was working on rs690 and currently it doesn't cover rs600 chips
blathijs: Ah, right :-)
mmp: osiris_: anyway, thank you a lot; you sent a lot of time on this...
mmp: but still, there is a partial success :)
osiris_: mmp: so did you:)
mmp: hmm, there is rs690 documentation, though...
mmp: even calling itself RS6xx :)
osiris_: mmp: probably there're many common things in rs690 and rs600, but the most important unit (memory controller) is different on rs690 and rs600
mmp: osiris): yes, you're right; just that label RS6xx on website was quite promising...
agd5f: osiris_, mmp: I should be able to get you you guys the regsiters at some point next week
mmp: agd5f: :) that would be great
mmp: I'll try to be online ass much as possible, but still it will be only a fraction of time I could devote it now :(
mmp: osiris_: hmm, I few hours ago sent mail to amd regarding the memory controller, and even now got the reply :)
mmp: (the question was regarding RS600 documentation globally)
agd5f: mmp: that alias maps to me and bridgman :)
mmp: agd5f: :-))
mmp: well... you'll probably find new mail in your mailbox then :)
mmp: I didn't know you work directly for AMD :)
mmp: well, man learns his whole life :)
agd5f: :)
mmp: agd5f: sorry for unneccessary spamming then :)
agd5f: mmp: no worries, that alias is for development questions
mmp: good night all :)
ethana2: awesome work you guys
ethana2: i've been trying to help the ubuntu devs fix a bug with the default resolution used by my machine in 8.10
ethana2: the performance seems awesome, this last version
ethana2: well, good day
vehemens: airlied: what does radeon gem do? dri2?
rx__: memory management
gentoofu: dri2 summary/insight -> http://www.phoronix.com/forums/showthread.php?t=8671#post28360
vehemens: rx__: memory management to what end? performance?
vehemens: gentoofu: it was more of question on far along he was
gentoofu: "TTM was fathered by Tungsten Graphics. The advantages for this video memory manager is dynamic tracking of buffers, full access to all addressable video memory for every 3D context, a fence facility for hardware synchronization, and a guarantee that textures and video memory buffers will be preserved. Intel views its GEM implementation as much simpler than TTM while still offering all of the memory management benefits."
gentoofu: and yes, you get performance out of GEM
gentoofu: http://www.phoronix.com/scan.php?page=news_item&px=NjQ3Ng
gentoofu: man, i didn't even hafta answer since the question was aimed towards airlied lol
vehemens: gentoofu: performance is good. no tearing is good.
vehemens: gentoofu: but has he gotten radeon to the point of dri2 direct rendering?
rx__: dri2 needs to be reworked for gem
vehemens: rx__: got it. i see the xserver sledgehammer commit. sigh...
damentz: so are you guys using gem for radeon?
damentz: i mean, intel is making rapid progress, makes sense to implement under their code
damentz: they say it's simpler anyway
rx__: damentz; considering airlied has a branch for radeon-gem.. possibly :)
dmb: will gem work with gallium3d?
dmb: or does that require ttm?
rx__: it should work
damentz: rx__: awesome
damentz: i think someone like intel probably is a little more reliable when they are making billion profits
damentz: :)
pbdl: hello
pbdl: agd5f, airlied, are you around?
pbdl: i was here yesterday about the missing S-video from xrandr's output (not disconnected, but non existent), and was told that Mobility Radeon x700 had it off in the driver
pbdl: i went to console only, ran 'atitvout -f t' which brought the display over to the TV, and 'radeondump -d radeondump-after-atitvout'. I have the dump ready if youre still interested
pbdl: i couldn't run vbetest, it said i wasn't in console only
airlied: vehemens: dri2 isn't written yet.
airlied: vehemens: so I can't implement it
airlied: radeon so far is using a GEM like API wrapping TTM internals