agd5f: airlied: Bug 16512
arekm: builds here fine on few x86, x86_64 and ppc (but I'm regenerating am/ac/lt and didn't test without regeneration)
airlied: agd5f: yeah I should fix that :)
airlied: lemme look at the server..
MostAwesomeDude: Hmm, builds fine on the laptop...
agd5f: too bad ther's no common swapping functions
MostAwesomeDude: Oh, wait, I'm not at the HEAD. One sec.
agd5f: everyone's gotta do it different
airlied: MostAwesomeDude: its BSDs.
agd5f: MostAwesomeDude, arekm: non-linux
MostAwesomeDude: Want me to test anywaY?
airlied: oh christ the configure.ac stanza in the server is huge.
airlied: really should be added to the util macros.
MrCooper: isn't it really about (non-)glibc?
MrCooper: there are BSD systems with glibc...
airlied: MrCooper: yup the kFreeBSD guys or whatver mgiht be okay.
agd5f: airlied: might be easier to just define a local swapping macro
airlied: it appears even Open and other BSDs don't agree.
MrCooper: how could anyone agree with OpenBSD? ;)
MostAwesomeDude: MrCooper: The trick is to agree with its devs.
airlied: the quicker modesetting is in the kernel the quicker I can ignore this :)
airlied: okay first attempt at fixing it in the tree now.
MrCooper: airlied: couldn't you just use the MMIO_IN*() macros or something like RADEON_BIOS*() for ATOM byte-swapping?
airlied: MrCooper: not really.. way too invasive..
airlied: and not just reading regs/or bios image
MrCooper: this stuff is in hot paths?
airlied: MrCooper: its in the atombios interpreter.
airlied: MrCooper: wait until you see benh's patch :)
airlied: MrCooper: buts it mostly a matter or you don't know when you read from the BIOS whether it needs to be swapper yet.
airlied: the atombios does some really nasty things, reading 32-bit and using 8-bit pieces of it..
MrCooper: okay, but how does that matter for the choice of byte swapping macros?
airlied: MrCooper: because RADEON_BIOS read from VBIOS, and MMIO does MMIO.
airlied: so I just used real OS macros :)
airlied: instead of rolling yet another set.
airlied: granted I really cared more for getting this into shape for the kernel..
MrCooper: airlied: the point is RADEON_BIOS* convert little endian to native byte order
airlied: but I might not need to do that anymore.. fingers crossed.
airlied: MrCooper: okay I could have generalised those macros to not read from VBIOS
MrCooper: right, the OS macros turned out to be so much less hassle ;)
Zajec2: z3ro: ping
glisse: agd5f, airlied: ok so i pushed the flush/wait thing that fglrx does
glisse: it's not exactly like fglrx though
glisse: fglrx do more then 64 dummy register write after to fill the fifo
glisse: i got similar patch to push for drm blit
glisse: will do later when i got time
fpoibaf: Just to let you know that I have converted the "Feature Matrix for Radeons" created by Corbin, with his permission, to the FDO wiki at:
fpoibaf: Contributions are welcomed!
quicksilver: fpoibaf: why "GOL" not "GOLD"
fpoibaf: ´╗┐quicksilver: for some reason the wiki does not let you insert GOLD, so I trunkated to GOL...
quicksilver: wow. how strange.
moondrake: fpoibaf: it probably sets of some spam filters, spam for WoW (and others) gold is common on wiki's
mjt: hmm. No r700 ?
mjt: Radeon HD3200 built in 780G - is it "r700" ?
gustaf1: how well is rotation accelerated in -radeon?
gustaf1: I'm using two 1600x1200 monitors, one being rotated. When scrolling in Firefox3 on the rotated screen, it's very slow, and I see the re-paints (from left to right, which would correspond to up-down) is clearly. When scrolling on the non-rotated screen, it's faster and the re-paintings are visible but not that obvious..
gustaf1: I'm using EXA
gustaf1: (btw, type G0LD with a zero instead of capital o)
airlied: gustaf1: got drm loaded?
gustaf1: yep, but glisses lockup-free branch from agd5f's repo, so not master git
gustaf1: dunno about its age...
airlied: shouldn't affect rotate as long as its therer.
airlied: gustaf1: is that an r500 card?
airlied: is it just firefox that is bad? or do other apps go slow as well?
gustaf1: I notice now, that it's much slower on "large" pages, such as /.
gustaf1: perhaps firefox creates one very large pixmap or something..
gustaf1: just Fx so far
airlied: its more likely doing a lot of damage which is cauing a lot of roates
airlied: so it could be just stupid firefox.. not sure we can do anything in the driver
airlied: it might be interesting to try and hget sysprof or oprofile traces
airlied: gotta run..
gustaf1: the re-paints are visible not only because you see clear "lines" where certain parts of the page has been moved before others, but also because these aren't purely vertical lines, they are kind of jiggy..
glisse: gustaf1: might also be the reset function which keep resetting the gpu
glisse: things is we don't have proper gpu lockup detection
gustaf1: ah, yeah
gustaf1: (works more smoothly in a large document in gedit)
glisse: so we might think that the gpu is lockup while it's only busy moving some big texture
gustaf1: and this affects your lockup-free branch more... sounds reasonable.
gustaf1: you really should _know_ when to lock or not.. isn't this documented from ATI?
glisse: as we assume that if gpu is not going idle after small amount of times it means it locked up
glisse: gustaf1: when hw go crazy there is no reliable way to know :)
gustaf1: sure, but from your commit logs, you've been looking at how fglrx is doing things. this indicates uncertainty from the docs? or simply put: reality extends the docs
z3ro: glisse: btw did you push the blit lock fix? I could test that out and see if it helps with my lockups.
z3ro: gustaf1: the docs say nothing about proper locking or sync.
glisse: agd5f: btw can you ask to Dominik is RB2D block really to be avoided ? i saw fglrx flushing through rb2d and not through e2 block
glisse: z3ro: well i push one fix in the ddx
glisse: the drm side needs same kind of things in the texture upload path and in the blit path
z3ro: I see. let me know when it's all committed and I'll do some testing.
glisse: well if i got time tonight to cleanup my drm tree i will push them
z3ro: ok. I probably should get some sleep in a few hours though. I need to be awake in the day to get my visa etc sorted out. =/
glisse: sadly in our economic world it's easier for goods to travel than for human ;)
z3ro: hehe wasn't there someone who mailed themselves to another country inside a shipping crate? :P
z3ro: actually that would probably give you more room than economy. :P
glisse: but i guess unpressurized luggage compartiment might do you no good
z3ro: I'm pretty sure it would be illegal, too. ;)
glisse: the system doesn't like cheater :)
z3ro: that would take some explaining... "Uhhhh, well..."
glisse: food time :)
TobiasTheCommie: wait, uvd being opened(sans drm) on the rv770.. nice... :)
TobiasTheCommie: or rather, might be
Zajec2: z3ro: :)
Zajec2: z3ro: do you already hate me? ;)
z3ro: Zajec2: no, just forgot about the ping before.
Zajec2: i was afk anyway
z3ro: Zajec2: I'll try to get the patch finished tonight, but things keep getting in the way.
MrCooper: gustaf1: 'jiggy' sounds like maybe the rotated quad is drawn as two triangles and there's tearing between them
gustaf1: I just wanted you to know "how" it looked so you could understand what kind of drawing was done..
MrCooper: if it's that then it should be possible to fix the worst problem by using a different 3D primitive
Firiban: hi all
adamk: Firiban, Morning.
Firiban: adamk: yesterday you mentioned that fedora has up-to-date libxcb packages, didn't you?
adamk: Firiban, Well, I never had to update libxcb to get a newer xserver to compile.
Firiban: if fedora or any other distro has precompiled packages - can i just extract them and move the files to their position in my /opt/gfx-test or will that cause problems?
adamk: Firiban, I would not recommend that. It might work, but it might cause problems.
osiris_: glisse: kudos to you! your flush&wait patch fixed exa for me. I had to use migrationheruistic greedy, to get usable desktop before. without that option pictures in firefox was disappearing and I was hitting many other graphic glithes. it's fixed now!
osiris_: hope that soft locks got fixed too (didn't hit any since applied your patch)
glisse: osiris_: this patch is not enough to fix lockup on touchy card
agd5f: glisse: for the exa case, why not send the flush and wait_until in the done() function rather than after every draw?
glisse: agd5f: i got the feeling that you should not start a new draw before the previous one is done
glisse: but fglrx doesn't seems to stick to one rules here
agd5f: seems like a lot of stalling
glisse: sometimes i see flush & wait btw blit sometimes not
glisse: i think it's safe to do it in done
glisse: i need to check again but now that i think to it i think fglrx only flush when 2d blit command change
glisse: like not same stride
glisse: or not same brush
agd5f: in which case, done() should be fine
glisse: one things is sure is that before doing 3d you need to wait for dma & 2d idle
glisse: i think this is a consistant pattern in fglrx
glisse: agd5f: btw would be nice to find out if its better to go through rb2d for dstcache_flush
glisse: fglrx use rb2d not e2
agd5f: maybe it would be better to add the wait_until 2d idle at the top of 3D stuff rather than after each command
glisse: agd5f: i am not sure
glisse: agd5f: i think that fglrx do a wait until once in while in 2d cmd stream
glisse: just to calm down the engine ;)
agd5f: we should probably update the sync counter as well
glisse: agd5f: well i got some more test to do with wait & flush to see if that helps then if i still see lockup this means that we do somethings wrong somewhere in the 3d engine
glisse: btw i don't have dump handy but it seems fglrx translate quad strip into triangle strip
glisse: i need to double check but i think fglrx avoid quad rendering
|moe|: hi, does the 184.108.40.206-72 kernel from koji support the rs690-chipset better than the ones before? are there improvements concerning the maximize-infinite-loop?
arekm: wrong channel?
|moe|: no the rs690 is a ati-built-in chipset, also known as x1250
|moe|: and the newer kernels (above 4-30) freeze when maximizing a window
arekm: so use vanilla kernel or somthing (no idea what koji is)
|moe|: actually not the kernel freezes but the xserver
|moe|: points arekm to http://koji.fedoraproject.org/koji/packageinfo?packageID=8
|moe|: lots of kernels, more actual than the ones in the repos
arekm: oh. I don't use fc
|moe|: that explains a lot ;)
|moe|: used ubuntu before that, no probs either with the radeon module or with fglrx, but my wlan-adapter is not supported natively
|moe|: so i ran into many issues with connectivity
|moe|: arekm which distro do you use?
arekm: hardcore one, pld-linux.org
|moe|: sounds interesting, which kernel does it use?
|moe|: ok, reading is supported ;)
|moe|: found it
|moe|: anyone on the RS690M-topic?
adamk: It's been a rather quiet day here :-)
|moe|: *g* must be due to the championship
|moe|: i'm really excited about uit
adamk: I don't have an RS690, but an RS485... No problems here.
|moe|: which kernel do you use?
adamk: But I've updated my DRM from git.
|moe|: is there a howto available?
|moe|: and for what reason did you actually update?
adamk: I've built Xorg from git a number of times in the last 5 years, so I didn't follow the guide.
adamk: |moe|, I've almost always tested the latest code in git.
adamk: I'm not sure if the radeon DRM module in fedora supports the rs485 and rs690 cards (or the r500 cards I have in my non-laptop machines).
|moe|: adamk, this should tell me something, doesn't it?
adamk: What is "this" ?
|moe|: the testing of the git
adamk: I just don't understand your question, I guess. What should it be telling you?
|moe|: did you mean "now it is allright with an rs" or did you mean "...on my machines..."
adamk: The latest code in git works fine my RS485, as well as my non-laptop machines.
adamk: I do not know if they would be supported by the DRM in the Fedora kernel.
|moe|: I'm confused, doesn't all kernels use the same DRM? (please don't beat me up for that ;) )
adamk: Newer kernels use newer versions of the DRM. And, of course, each distribution can patch their kernels to use whatever version of the DRM they want.
|moe|: *sigh* maybe I should attend some kernel-building-classes
adamk: You could simply try updating the DRM kernel modules using this guide: http://wiki.x.org/wiki/Development/git
adamk: But, again, the Fedora 9 kernel (assuming you're using Fedora 9) may already include the necessary support.
|moe|: I am using fedora, but my problem is that the xserver ends up in an infinite loop when using a kernel newer than 220.127.116.11-30
|moe|: thank you very much, will try to change my new kernel with the git-drm, so my working on is not touched at all
|moe|: do I have to uninstall the older modules or can you just overwrite it?
adamk: You can just overwrite it.
|moe|: great, thank you so much
|moe|: will try tomorrow, now i have to go to attend the semifinals!
|moe|: will report
mikkoc: |moe|: to the stadium?
|moe|: mikkoc: unfortunately not, but a beer-garden is 9 yards ;)
enouf: er, use #ati ...or... see #ati channel ?
agd5f: glisse: why are you waiting for GUI DMA idle?
ethana2: Hey, I have a Radeon 9200SE
ethana2: it's performance last time I used it was about half that of under windows
ethana2: about twice the integrated
ethana2: so I just took it out
ethana2: Have there been enough advances in the driver to warrant giving that card another try?
agd5f: ethana2: depends when you last tried. also, ther eare some dri options yo can enable to improve performance
ethana2: well, ubuntu hardy....
ethana2: I didn't see updates for it recently
ethana2: so its as good as two months ago I guess
ethana2: I was under the impression that those parameters sacrificed a bit of stability....
ethana2: but it may be worth it for me...
ethana2: could you give me a URL to a page detailing those?
ethana2: with your general reccomendations?
agd5f: enable hyperz in your .drirc
ethana2: I am not familiar with .drirc
ethana2: /etc/.drirc ?
ethana2: ..nope, not there
ethana2: yeah I don't know where that file is
ethana2: ok, now I'm confused
ethana2: should I create this file, or should it already exist somewhere?
ethana2: I see references to ~/.drirc, but not only does that not exist on my system
ethana2: I wouldn't think anything in ~/ would have anything to do with hardware configuration
agd5f: ethana2: creat it if it doesn't exist. the one in /etc in the global one, the one in ~/ is your user preferences
agd5f: it's 3D preferences
ethana2: oh, ok
ethana2: ethan@ethan-desktop:~$ gedit .drirc
ethana2: ok, now I'm not sure what I should put in it
ethana2: Well I should ask this
ethana2: I'm getting a new laptop soon
ethana2: nvidia geforce 8400m gs
ethana2: do you think the potential for performance improvement on this desktop is worth the trouble?
ethana2: or would you say that when such features in the driver become stable enough, they'll be turned on by default?
ethana2: ....or would you say, perhaps, that because of the age of the card, the changes to its driver have slowed and its best to recycle or trade up?
agd5f: ethana2: other than bug fizes, not much new happending with r200 class cards
ethana2: I see
ethana2: ....in that case, I think I'll opt not to bother with it again
ethana2: thank you for your time
agd5f: ethana2: http://dri.freedesktop.org/wiki/ConfigurationInfrastructure
agd5f: use xdriinfo to browse the options
agd5f: it's all runtime configurable, no restart required
ethana2: although I don't know if PCI is hotpluggable ;)
elbeardmorez: hello. I get a segmentation fault running either glxgears/info with my new git setup. the following is a gdb backtrace of glxgears if anyone has a mo to comment please? http://pastebin.com/m240e9638
agd5f: elbeardmorez: looks like it's trying to use dri2 which is not yet supported on radeon.
JyZyXEL: how do you debug why radeon has no Direct rendering enabled?
agd5f: JyZyXEL: LIBGL_DEBUG=verbose glxinfo
JyZyXEL: how does that help?
agd5f: and check your xorg log
JyZyXEL: oh ok
JyZyXEL: the log is 1055 lines already btw
JyZyXEL: how am i gonna identify whats wrong
elbeardmorez: agd5f: ok sorry and thanks! I meant to ask ages ago.. is there somewhere I can look in order to keep up to date on your / 'radeon' development progress please ..and hence avoid asking obvious questions?
agd5f: make sure direct rendering is enabled in your log. look for: Direct rendering enabled
agd5f: JyZyXEL: if you log is ok, it's probably a lib problem, in that case try LIBGL_DEBUG=verbose glxinfo
JyZyXEL: ok ill try it tomorrow cause im so drunk atm
agd5f: elbeardmorez: I suspect you build your xserver wrong or something as the driver should still work with, jut use the old dri stuff
ethana2: out, good day all
hifi: are some of these extensions slow on 9600 pro (r300): GL_EXT_compiled_vertex_array, GL_ARB_multitexture and GL_NV_texture_rectangle
pepie34: Hi guies
pepie34: yesterday i've come to this channel
pepie34: to say that i can't run opengl application with the last open source radeon driver
pepie34: even if glxinfo and xorg.log.0 looks good
pepie34: I get this when i run glxgears
pepie34: Error: couldn't get an RGB, Double-buffered visual
MostAwesomeDude: That's right, I remember that.
adamk_: Yeah, me too.
pepie34: Is anyone thinking of an other way to search
MostAwesomeDude: And I've had that problem before, but I can't remember what caused it.
adamk_: I think we both took a stab at it, but /var/log/Xorg.0.log looked good, and glxinfo showed direct rendering...
MostAwesomeDude: Was it AIGLX, maybe
adamk_: Not having AIGLX enabled shouldn't cause glxgears to not work.
pepie34: Section "ServerFlags"
pepie34: Option "AIGLX" "off"
pepie34: why ?
MostAwesomeDude: Sorry, I'm trying to remember why it didn't work.
pepie34: ok mut disconnect to test with aiglx on
pepie34: bye for few minutes
pepie34: ok i've got some clue
pepie34: now with AIGLX on i've got
pepie34: (**) Option "AIGLX" "on"
pepie34: (**) AIGLX enabled
pepie34: (EE) AIGLX error: dlsym for __driCreateNewScreen_20050727 failed (/usr/lib/dri/r300_dri.so: undefined symbol: __driCreateNewScreen_20050727)
pepie34: (EE) AIGLX: reverting to software rendering
pepie34: on the Xorg.log
adamk_: That might be related...
adamk_: Can you pastebin the full output of 'LIBGL_DEBUG=verbose glxinfo' ?
pepie34: the build process seems to be ok
pepie34: I did it yesterday
adamk_: Yeah, I'd like to see it again, if you don't mind :-)
pepie34: ok next time
adamk_: I think that's telling us that your r300_dri.so is old. Are you sure that's the one you built from mesa git?
MostAwesomeDude: Got it!
MostAwesomeDude: You didn't rebuild Mesa after building X!
pepie34: I did not build X :)
pepie34: I follow the tutorial on phoronix
adamk_: Oh, well in that case, AIGLX is not likely to work at all.
adamk_: What's version of the X server? It should be the first line or two from 'Xorg -version'?
adamk_: Well it's mesa 7.1 rc1, so that should be new enough for r500 support.
pepie34: X.Org X Server 18.104.22.168
pepie34: Release Date: 5 September 2007
pepie34: X Protocol Version 11, Revision 0
pepie34: Build Operating System: Linux Ubuntu (xorg-server 2:1.4.1~git20080131-1ubuntu9.2)
pepie34: Current Operating System: Linux magritte 2.6.24-19-generic #1 SMP Wed Jun 18 14:15:37 UTC 2008 x86_64
pepie34: Build Date: 13 June 2008 01:10:57AM
adamk_: Alright, the X server definitely needs to be updated for AIGLX.
adamk_: Maybe it needs to be updated for direct rendering, too? I didn't think that was necessary.
pepie34: I don't want to mess with updating the X server
adamk_: The developers could definitely answer this, but they all seem to be idling.
pepie34: xorg edgers on ubuntu package are not really fun to play with
adamk_: You could try asking on the xorg-driver-ati mailing list ( email@example.com )
adamk_: They would at least be able to say if a newer X server is necessary for direct rendering.
pepie34: thanks guy
adamk_: Please let us know how you make out.... You could also try asking on here again, but I would suggest a different time of the day since you've struck out here twice around the same time.
pepie34: may be because that the only momen i can
pepie34: ok got the answer
pepie34: #13 and #14 answers
adamk_: Well that would solve the AIGLX issue... But, mind you, he even says that glxgears works for him.. You're not even getting that.
agd5f: you need a new xserver for AIGLX with the latest mesa, but regular drect rendering should work fine.
adamk_: agd5f, Any idea about why he's getting that error message from glxgears, though?
agd5f: adamk_: what error message?
agd5f: output looks fine unless I'm reading the wrong link
adamk_: agd5f, glxgears gives him "Error: couldn't get an RGB, Double-buffered visual"
adamk_: /var/log/Xorg.0.log looks good (except for the AIGLX problem, but we know about that) and glxinfo, as you've seen, looks fine.
agd5f: adamk_: that's fine, gears still works
adamk_: My impression, from talking to him yesterday, is that it didn't work.
adamk_: But I'll double check with him next time I see him on here.
adamk_: I guess I never did hear him say that glxgears was giving that error and not showing any gears, just that he was getting that error.
agd5f: ask him next time he's on. I think it should be ok
adamk_: Heh... It'd be funny if we had him go to do all this stuff (enabling AIGLX, posting log files, and glxinfo) and there were no problems to begin with :-)
agd5f: airlied, glisse: anything else you want to get in 6.9.0?
Sadako: hey, I'm using the radeon driver along with mesa, drm and xorg-server from git with an x1950, and the memory usage after startx is around 280mb, whereas it's typically around 55
Sadako: with the same setup but radeonhd from git it's still around 55mb, so anyone know the cause?
vic: do movies still flicker with the open-source drivers? i plan on compiling from git. has that been supported yet?
vic: (playing back a movie running compiz)
adamk: vic, If you use the textured video xv port, it works fine.
adamk: Sadako, As I understand it, what you see in top is also the mapped video ram.
airlied: agd5f: I'm seeing an issue on an rv630 with two vga monitors attached.
airlied: agd5f: actually you already fixed it :), /usr/lib vs /usr/lib64 in my testing
airlied: I was still getting the old binar.
roh: č/window net
spstarr: looks at roh, is that some cryptic epix command? ;)
Sadako: < adamk> Sadako, As I understand it, what you see in top is also the mapped video ram.
Sadako: that sounds quite odd, but it's using 256 mb vram so it would actually add up...
Sadako: I'll set it to use half that in xorg.conf in a bit and see if the memory usage is reduced
GerbilSoft: recent xserver update apparently broke all bitmap fonts except fixed :(
GerbilSoft: (on plain old X apps at least - works fine on KDE apps)
vic: GerbilSoft: try compiling with --disable-builtin-fonts
GerbilSoft: vic i'll try that in a bit
GerbilSoft: working on building a new server right now (we finally got the replacement board :D)
vic: it was recently enabled by default
MostAwesomeDude: Hey, so a couple guys moved the matrices to the Wiki, I guess.
MostAwesomeDude: http://wiki.x.org/wiki/RadeonFeature and http://wiki.x.org/wiki/RadeonProgram .
rx__: what's yellow mean?
rx__: in progress?
MostAwesomeDude: rx__: Yellow is WIP.
MostAwesomeDude: The program list uses WineHQ-like colors.
MostAwesomeDude: (It would actually pretty cool to have a cross-index of DRI and WineHQ, but somehow I think it would be too much work. :3)
rx__: huh.. i thought winehq used platinum, gold, bronze, and garbage
MostAwesomeDude: Yeah, they do, but Gold and Bronze are too close to each other in terms of color.
MostAwesomeDude: ...It was like 4 in the morning, okay?
MostAwesomeDude: Anyway, can anybody tell me what a two-sided stencil is, and what it's used for, and how we fake it?
MostAwesomeDude: Or does anybody want to help me dig through the vertex program and finish off fog coords?
rx__: wonders why it says g0ld
rx__: someone didn't do a good job OCRing :P
MostAwesomeDude: rx__: One of the Wiki maintainers does it.
MostAwesomeDude: I'm gonna assume he had a decent reason.
rx__: the r500 is looking good
MostAwesomeDude: rx__: I filled in most of that data, and I only have r5xx cards, XD
dmb: so secondlife works fine?
dmb: makes it better then fglrx, where secondlife doesn't really work
airlied: MostAwesomeDude: there is a GL extension description for it somewhere.
MostAwesomeDude: airlied: Yeah, it didn't really make sense last time; let's see if I understand it now.
MostAwesomeDude: Ooh, instead of two stencils, this is usually done with one two-bit stencil buffer?
airlied: MostAwesomeDude: I fail GL after 1.1 :)
airlied: MostAwesomeDude: I mostly fail at GL 1.1 now I would guess, its been 4 years since I wrote GL on the app side :)