soc: hi
libvde: hi soc :)
soc: hi libvde
soc: anything new?
soc: i guess i'll try exa now ...
soc: installed it yersterday, but didn't try it because it took too much time to download the whole kde4 stuff in repos :-_/
soc: how can i see if it works?
soc: i guess the ati open source resistance group threw chairs around after your article :-P
soc: nice blog
Tigerchen: soc: which blog-entry are you referring to?
soc: luc's
soc: mhh works ... nice!
Tigerchen: libv: you here atm?
libv: Tigerchen: i am it work yes :)
Tigerchen: libv: have you been able to reproduce the bug?
libv: Tigerchen: i only just arrived :)
libv: but i have that laptop with me, yes
libv: heh, phoronix already benchmakred the drivers it seems
libv: we're doing quite well for not having cp and thus dma support
soc: yes ...
soc: the performance delta between XAA and EXA is quite big ...
libv: soc: yes, i think the statement is "exa sucks, news at 11" :)
soc: and fglrx looks like the a) either they stole the xaa code or b) XAA performance is at the theoretic maximum ...
libv: soc: well, we are using only the mmio path
libv: soc: and most of the things we can do through the mmio path map reasonably well to XAA
libv: soc: plus, mmio is pretty io bandwidth intensive, and it requires constant attention
libv: but it is fast
soc: mh ok
libv: exa performance sucks, because we do not have the command processor and therefor we do not have dma for up/download
soc: do i need xorg.conf settings for activating exa/xaa?
soc: wouldn't be xaa + command processor/dma then much faster?
libv: soc: faster, i do not think so
libv: soc: we would then just fill a buffer and then tell the cp to get to work
libv: soc: better cpu wise
soc: ah ok ...
soc: so xaa depends heavily on the cpu? so on a 486 exa would be faster?
libv: no, xaa exposes different accelerations than exa
libv: soc: the way we access registers now is more cpu intensive than when we use the command processor
libv: soc: plus we take up quite a lot of mmio bandwidth
libv: soc: this is no different between xaa and exa, as both poke mmio directly
libv: in our driver, for the time being
snipex77: hey libv
libv: khorben: can you gdb attach to your X server when it is "hanging"
libv: khorben: if you bt it, then you should end up in one of the virtual selection routines
snipex77: libv : according to the readme file for rhd_conntest, " sudo rhd_conntest 01:00.0 -s" should be correct command
snipex77: 01:00.0 is PCI tag
snipex77: -s is additional option
snipex77: but im still getting very short output
snipex77: Load Detection: RHD_OUTPUT_DACA
snipex77: HotPlug: RHD_HPD_2
snipex77: DDC: RHD_DDC_0
snipex77: DDC Line[0]: Slaves: 6e a0
snipex77: [boris@localhost ~]$
khorben: libv: not now, maybe around 20h this evening
libv: khorben: ok :)
khorben: this time I did a "make clean" first, re-generated Makefiles etc, but it did not help
snipex77: libv : some help ?
libv: snipex77: did you read the README?
libv: snipex77: "computer says no"
snipex77: yes i did read readme !
snipex77: but im just a newb, you could help me out !
libv: snipex77: do remember what i told you to do?
libv: +you
snipex77: no
libv: 21:40 < libv> snipex77: can you read the documentation of conntest, and then send a full runof all outputs to the mailinglist?
snipex77: what does that mean ?
snipex77: all outputs ?
libv: 15:22 < libv> snipex77: did you read the README?
snipex77: yes
libv: then read it again
Tigerchen: snipex77: ./rhd_conntest
libv: parameters have nothing to do with it
snipex77: what does -x num mean ?
libv: but then again, it is all explained in the readme
snipex77: libv: ive read the readme but i dont understand it completely !!!
libv: "Background information:"
snipex77: DACA, DACB, TMDSA and LVTMA
libv: "Procedure for standalone graphics cards:"
snipex77: k
libv: which you of course also read when you read the README
snipex77: Currently up to 4 outputs are possible: DACA, DACB, TMDSA and LVTMA.
snipex77: 4 outputs ???
snipex77: what 4 outputs
snipex77: i dont get it
libv: READ.
Death_Syn: i have at lesat 3 of those outputs available to my cared
Death_Syn: er card
snipex77: so i have to change my graphics card cables or what ?
snipex77: and save the data rhd_conntest spews out with each cable ???
libv: snipex77: as described clearly in the readme
snipex77: english is not my main language
snipex77: so im having little trouble reading the readme
libv: snipex77: same here, but you serem to be managing on irc just fine
snipex77: forget it
snipex77: i dont know where to put these cables
snipex77: besides, my dad set up card
slackern: libv: there?
libv: slackern: yes, but busy on a non radeonhd issue atm :(
libv: slackern: but do explain what issue you are seeing :)
slackern: libv: ahh just wanted to say that i ran into the issue with it saying no EXA acceleration available so it reverts back to XAA and gives me a black screen without any possiblity to change to a console or anything
libv: slackern: right, this is X hanging somewhere i think
libv: slackern: can you kill X remotely?
slackern: libv: I haven't had the possibility to try it im afraid =/
slackern: libv: hitting ctrl+alt+del a couple of times reboots it atleast
slackern: libv: Im in windows right now doing some work, but thought maybe i could get some ideas to get some information to you in case you need
libv: slackern: i think my changes to virtual calculation are now making the thing loop endlessly under some circumstances
libv: slackern: i have looked at it again, but couldn't immediately spot why
slackern: libv: ahh i saw you mention something like that, this card is a X1950Pro AGP card
libv: slackern: right, actual card shouldn't make a difference :)
libv: slackern: right now i'm hoping that this is the same issue, and that it is some eternal loop somewhere
libv: and that, by remotely gdb attaching, and then backtracing, plus some dumping of some local variables, it will become clear why this is happening
slackern: libv: hehe, im not all too much into that debugging im afraid, but maybe you could give me some commands i could toss at it a little later when im done working in windows?
retrry: Just installed the driver :) Everything works fine - I'm amazed
udovdh: hello, back home
udovdh: good job, retrry
udovdh: slackern, did you ctrl-lalt-backspace?
retrry: except the video - it sucks :)
udovdh: well, no 2d/3d yet
udovdh: and you decide on the content
slackern: udovdh: Yes i tried that too, it's just a black screen, like the everything is running fine but the graphics crashed the card or something :p
udovdh: got a log, slackern ?
udovdh: can do a `X -logverbose 7`?
slackern: I will have to give it a try in a little while, in windows now doing some stuff right now =/
udovdh: wow I see EXA in get for R5xx...
udovdh: is OK slackern, just send the devs the log when you get it
udovdh: and XAA too
libv: slackern: can you trigger it
libv: slackern: and then log in remotely
libv: and then find out the process number for X
libv: and then run gdb
libv: and then type: attach
slackern: hey again, managed to get some logs now and i got past the black sceen when passing AccelMethod "none" but it's kind of sluggish now ^
slackern: couldnt do a gdb trace since X was completely gone also when i connected to the machine
slackern: http://pastebin.ca/884749 when running with "none" option which gives a working but sluggish X
slackern: log with EXA http://pastebin.ca/884750
slackern: oops sorry managed to crash X :)
libv: so with none it works?
slackern: Yes it runs like that right now
libv: slackern: where does the log end when you do run with XAA?
libv: actually... could this be an undefined symbol?
libv: slackern: can you run ... lessee
libv: slackern: nm radeonhd_drv.so | grep R5xx2DSetup
libv: wherever your binary lives of course
slackern: U R5xx2DSetup
libv: there we go :)
libv: undefined :)
slackern: hehe
marcheu: someone didn't run autogen :)
libv: slackern: can you run autogen again?
libv: :)
slackern: ahh autogen, i've always just done ./configure --prefix=/usr :)
slackern: ok ran it now, want me to give it a spin with EXA or XAA?
slackern: It ran with EXA now, but it's painfully slow, taking ages to do anything :p
libv: :)
libv: slackern: does it the log confirm that it is exa?
slackern: struggles to type out a sentance here :p
slackern: (**) RADEONHD(0): Selected EXA 2D acceleration.
libv: this is the configuration thing
libv: is it actually running exa?
libv: because exa could still fail, and then we try to handle it gracefully
slackern: hmm how can i verify it?
libv: further down
slackern: ahh will check takes like 10 seconds to switch windows now :p
libv: in screeninit it gets initialised
libv: :)
libv: go to XAA
libv: hrm, it shouldn't be _that_ slow
slackern: (II) EXA(0): Driver registered support for the following operations: and it show things like solid and that below
udovdh: can we verify XAA/EXA/etc while running xorg by runnign some tool?
libv: udovdh: no idea for that, xdpyinfo maybe?
libv: slackern: right, that's it :)
slackern: want me to try XAA?
slackern: it can't possbly be any slower than this :p
libv: slackern: should be better, yes
libv: should be roughly comparable to shadowfb
udovdh: can't test that myself yet, since I am using RV630?
slackern: ok, brb restarting X
udovdh: and shadowfb is what R6xx is on now, if I recall?
libv: udovdh: yeah, still no hw acceleration there
slackern: that was alot quicker
udovdh: I saw the code while browsing the git history
libv: slackern: right :)
udovdh: so works well, slackern ?
libv: slackern: phoronix benchmarking is quite funny to see
udovdh: benchmarking? which/where?
slackern: Yes i guess, i see the same behaviour when marking on the desktop as i did with the fglrx driver now :), struggles like crazy to draw that selection square :)
libv: ok... hrm
slackern: what is it that actually causes it to be so slow when doing that?, you know the coloured square you mark icons with on the desktop
slackern: it's lightningfast with vesa and older versions of radeonhd but now it's slow and stuttering like the fglrx always have been for me
udovdh: hmm, works OK for me, but this is no 2d/3d
udovdh: so the is an accelleration thing?
udovdh: do you see the square drawing trailing behind your movements?
udovdh: or?
udovdh: BTW:
slackern: It's like when it's 300x300 pixels it's fast but as it grows it slows down to a crawl struggling to redraw it
udovdh: if the bugs in EXA/XAA for 5xx are ironed out: release as 1.2.x
udovdh: so it is all lines?
udovdh: no blocks?
slackern: nah not really any blocks i guess, not exactly sure if i know how you mean
udovdh: testing that on 1680x1050: works ok
slackern: lets say, marking 1/4th of the screen takes 1 millisecond then half the screen takes 2 seconds and entire screen takes 10 seconds, numbers are a bit blown up though :)
slackern: maybe i could make a video of it to show
udovdh: would be best I guess to size the magnitudes in timings
udovdh: but it looks like there is room for some optimisations?
libv: udovdh: could be room yes, but i am not too certain whether we can completely fix this
udovdh: it is a first release... no worry
andrei: Hi, I have an X2100 and for some reason xrandr doesn't work
libv: slackern: well, fall back to shadow, but keep on testing things whenever we change anything to the 2d block
libv: slackern: for now, we need to get work on rv620/635 out
libv: andrei: hi, was just reading your email :)
udovdh: rc620/635 means also rv630 I guess?
libv: udovdh: no, the folloyups of rv610/630
andrei: libv, Hurrah :) thanks. I just tried the latest head, same problem (but its quite a bit faster)
libv: modesetting is altered quite significantly
libv: andrei: :) slackern here is saying the opposite :)
slackern: haha
libv: hrm... faster...
andrei: Running glxgears went from 200-300 fps to 1200
libv: andrei: are you certain? this seems like shadowfb
libv: andrei: can you verify that you are actually running xaa or exa
andrei: (II) RADEONHD(0): Using XFree86 Acceleration Architecture (XAA)
slackern: my glxgears gives me ~300
andrei: libv, Oh, one thing I didn't mention in the email; I probably should have. xrandr only reports one video mode for my card, I can't change the screen size either
libv: andrei: hrm... ah
libv: yes, m71 is still an r5xx
libv: andrei: right, the panel resolution is still very much fixed
libv: i only have initial scaling code sitting here (for more than a month already :(() no handling for it yet though
andrei: libv, Ah, okies. I don't mind, thought it might be something that would help explain what's going on :)
slackern: libv, Not sure if it matters or not, but the offical ati/amd drivers haven't worked for me since version 7.7 and up until 8.1 when using ati/amd's hotfix for certain agp cards, not sure if this card is some freak of nature or something
libv: andrei: but rotation doesn't work either?
andrei: libv, Nopes
libv: slackern: so you are using agp... i wonder if this could slow down mmio accesses
slackern: libv, indeed this is a x1950 pro agp card
udovdh: back...
libv: slackern: right, but it wasn't until you mentioned the hotfix for agp that i made the link :)
udovdh: I get 900 here on a rv630?
slackern: libv, they have been messing with it for quite some time now and they finally seem to have found some solution to it after 6 months :)
libv: udovdh: which is fully shadowfbed :)
udovdh: I know libv, but the 900 is the basis on which to improve, I understand
slackern: libv, there was discussion about the chipset drivers handling the new versions wrong with certain chipsets and especially the nvidia nforce2 which i ofc have
libv: udovdh: hopefully :)
libv: hrm, the kernel agp gart modules?
slackern: Not sure how it's handled in linux though, this was about the windows driver but i guess it's more or less the same
slackern: is it "AccelMethod" "ShadowFB" to switch to shadowfb again?
libv: yup
slackern: ahh great thanks
slackern: ahh marking on the desktop was fast again with shadowfb
dmb: :D
retrry: ShadowFB is an acceleration methon ? What is the differences between shadowfb and XAA/EXA? I can't find any information regarding this question :)
libv: shadowfb means that there is a copy of the framebuffer in main ram
libv: and that the cpu does everything
libv: and from time to time, the altered areas are copied over to the framebuffer
libv: so it is "fake" acceleration
libv: but it does help a lot
libv: more than actual XAA and EXA it seems :)
libv: with the fast cpus and wide pci-express busses we have
retrry: Thank you :) Can you point any tutorial about benchmarking 2d acceleration, smth like they did in phoronix ?
rx__: .. try gtkperf?
retrry: thanks, will try :)
mstrobert: I need to buy some video cards for our workstations. If I want the cards to Just Work with Ubuntu and the open-source radeonhd driver sometime in the coming months, is it more important to purchase R500 or R600, or are they both equally good choices? I'm not concerned with hardware video decoding, but I want them to drive dual LCDs and Compiz. Right now I'm considering the Radeon X1650PRO.
annonygmouse: Hi, anybody here? The last version of radeonhd doesn't seem to work for me, X crashes...
annonygmouse: on an ATI Technologies Inc M56P [Radeon Mobility X1600]
libvde: annonygmouse: did you run autogen.sh before recompiling?
annonygmouse: aaaah!
annonygmouse: I'm afraid not...
annonygmouse: Let me try again
annonygmouse: why the need? (If I may ask)
libvde: new files :)
annonygmouse: ahm...
annonygmouse: I'm going to try it
annonygmouse: brb
annonygmouse: thanks libvde
dvandyk: agd5f: hi. you wrote in your blog about the command processor. is there any documentation available on how to access it? how to setup the ring buffer?
annonygmouse: libvde: It worked like a charm, I'll try to get used to do the autogen.sh before make clean && make && make install
annonygmouse: Thanks to everyone!
annonygmouse: bye!
Agiofws: hey
Agiofws: agd5f,
Agiofws: i just as
Agiofws: i just saw a blog of yours announcing you are working for amd ? ?
agd5f: Agiofws: yes
agd5f: dvandyk: yes. take a look at the radeon drm
agd5f: dvandyk: http://cgit.freedesktop.org/mesa/drm/
agd5f: it's been more or less the same since the rage 128
dvandyk: ah, cool
Agiofws: agd5f, so ...
Agiofws: so amd si supporting for an opensource ? driver ? and a closed ONe ?
Agiofws: is*
Agiofws: so amd is supporting for an opensource ? driver radeonhd ? and a closed ONe fglrx? ? agd5f ?
Agiofws: agd5f, take a look at this bug http://ati.cchtml.com/show_bug.cgi?id=999 its mine ....
Agiofws: but since i installed radeonHD its not done that once
Agiofws: so i suspect a s/w issue not a hardware one
agd5f: Agiofws: I don't work on fglrx
agd5f: someone from that group will look at the bug though
Agiofws: agd5f, hwy does amd support 2 projects though ?
dvandyk: agd5f: is there any plan for a "processing only" radeonhd driver?
agd5f: we want to provide good open source driver, but we have obligations to fulfill with fglrx and there are some things we can't open source due to contractual obligations
agd5f: so we support both
dvandyk: agd5f: one that would just let me do dma transfers and run shaders?
agd5f: dvandyk: we are going to be releasing some code to do that soon.
agd5f: TCORE
agd5f: is what it's called
Agiofws: agd5f, how can i check using the radeonhd driver that my hd2600 is functioning ok ? is there any command ?
agd5f: Agiofws: right now all you can check is the display controllers
agd5f: no 3D support yet
dvandyk: agd5f: cool
Agiofws: example running fgl_rxgears with fglrx driver gave me only 600FPS on a duo core which means that something was wrong
Agiofws: yeas no 3d i know
Agiofws: agd5f, display controllers ?
Agiofws: whats that ?
agd5f: Agiofws: the part that puts the image on your monitor
Agiofws: ah... ok... :)
Agiofws: agd5f, one more how cani check my current version of radea
Agiofws: agd5f, one more how cani check my current version of radea
Agiofws: agd5f, one more how cani check my current version of radeonHD and compare to the currents git version ?
agd5f: Agiofws: ?
khorben: libv: sorry got busy
khorben: and now I don't have a second machine anymore :/
Agiofws: agd5f, one more how can i check my current version of radeonHD and compare to the currents git version ?
libvde: khorben: we found the issue :)
libvde: khorben: run ./autogen.sh
libvde: Agiofws: read your log, it is in there
libvde: Agiofws: ndim severely adaptated the git versioning script from my unichrome driver for radeonhd, and now we should know most of the time, from the log, which version you are running
Agiofws: yeah and how do i check for current git version ?
libvde: Agiofws: it is right underneath the list of chipsets
libvde: check our gitweb, or check the last git message sent to the ml, or whatever suits you
Agiofws: xorg.0.log ?
libvde: yes.
Agiofws: how ?
Agiofws: gitweb ?
libvde: Agiofws: it's all on the wiki
Agiofws: (II) RADEONHD: X driver for the following AMD GPG (ATI) graphics devices:
Agiofws: (II) RADEONHD: version 1.1.0, built from git branch master, commit bc885130 + ch
Agiofws: anges ?
libvde: what changes have you made :)
Agiofws: none
Agiofws: :)
libvde: sure :p
Agiofws: huh ?
khorben: libvde: I had tried, I can try again
khorben: libvde: that did it...
khorben: thanks
khorben: I'm not sure how I can notice a difference
khorben: (II) RADEONHD(0): Using XFree86 Acceleration Architecture (XAA)
mekius: does the xpress 1200 fall under the support of radeonhd?
mekius: hmm, nvm, seems to be r400 series
mekius: hmm, maybe not?