suokko: glisse: If you are interested about results running your kernel&radeon-rewrite with mobility 9200 see above
damentz: i expect fedora's rawhide to keep the latest xorg and mesa, so i'll follow that and let you guys know what's new
ikaiyu: anyone have radeon hd 2600pro from saphire and use on it ubuntu 9.04/arch-linux or slackware?
Sinuvoid: MostAwesomeDude
Sinuvoid: You there?
MostAwesomeDude: Sinuvoid: What's up?
Sinuvoid: Get a chance to run Ut?
MostAwesomeDude: Nope. Been busy with work.
Sinuvoid: okay
Sinuvoid: You mentioned profiling, what's that?
Sinuvoid: Maybe I could do it for you
suokko: Compination of "old drm modules" (2.6.30), new libdrm (modesetting), Jesse's ddx and radeon-rewrite causes exa o crash when starting to draw loging screen
suokko: http://antin.et/wesnoth/Xorg.0.log for log file
suokko: http://antin.net/wesnoth/Xorg.0.log
MostAwesomeDude: Profiling is when we use a system profiler, like oprofile, to gather statistics on the parts of the driver that are taking lots of time, and the parts that get used a lot.
nanonyme: suokko: Doesn't seem to work.
nanonyme: Oh, right. The first one had a typo.
nanonyme: Never mind.
otaylor: MostAwesomeDude: what's going to be hard is figuring out how to profile the gpu
otaylor: (especially since all the perfomance counters, etc, aren't documented)
nanonyme: And egh, X segfaults are always ugly. :(
ajax: i thought i saw some perfctr stuff in the radeon docs
otaylor: ajax: there are a couple of *mentions* of performance counters
suokko: nanonyme: yep
MostAwesomeDude: otaylor: GPU profiling shouldn't be necessary *yet*.
MostAwesomeDude: We have a lot of stuff that can still be squeezed out, and I expect that there's some code flow refactoring that can bring performance up too.
nanonyme: suokko: Btw, any specific reason why you're using a pre-release of X server 1.7?
otaylor: MostAwesomeDude: gnome-shell is very much gpu-blocked at the moment (or probably more likely gpu-memory-read-from-agp blocked)
Sinuvoid: MostAwesomeDude: How can I do this for you
otaylor: MostAwesomeDude: CPU profiling doesn't tell me anything about why it's slow
MostAwesomeDude: otaylor: Well, but it does say where things are taking a long time.
suokko: nanonyme: because I red that xserver in ubuntu is too old for DRI2
nanonyme: suokko: Sounds ridiculous to me. :P
suokko: Then I compiled master branch from git ;)
MostAwesomeDude: Sinuvoid: Are you on Mesa 7.3, or 7.4?
otaylor: MostAwesomeDude: Well, only if we inserted glFinish() throughout the code
nanonyme: I thought 1.6.1 should be plenty new enough.
suokko: 1.6.0
MostAwesomeDude: otaylor: Oh, it's using OGL?
otaylor: MostAwesomeDude: right now, it's telling me that it spends almost all the time when it finishes a frame
Sinuvoid: MostAwesomeDude: How do I find out
otaylor: MostAwesomeDude: Yeah, gnome-shell is a GL-compositor along the same lines as compiz
MostAwesomeDude: otaylor: Using glReadPixels() by any chance? :3
MostAwesomeDude: Sinuvoid: glxinfo
Sinuvoid: lol
Sinuvoid: Ok
otaylor: MostAwesomeDude: Not significantly
nanonyme: suokko: I'd probably personally just rather "steal" the stuff X server from Fedora than start using bleeding-edge git. :)
Sinuvoid: Mesa DRI R300 20060815 x86/MMX/SSE2 TCL
MostAwesomeDude: otaylor: Are you profiling into the DRI driver as well? That's where the useful stuff is.
Sinuvoid: MostAwesomeDude: Shouldnt that be R400??
Sinuvoid: Since that's the driver I'm using
suokko: nanonyme: It works just fine if I use Jesse's kernel and put my card to pci mode
MostAwesomeDude: Sinuvoid: There should be an OpenGL version field that says "1.3 Mesa-7.4" or similar.
nanonyme: Sinuvoid: R300 through R500 is similar.
otaylor: MostAwesomeDude: sysprof gives a pretty thorough overview
MostAwesomeDude: And no, r300 is correct.
Sinuvoid: ok
otaylor: even into the kernel
Sinuvoid: found it
Sinuvoid: 1.3 Mesa 7.3-devel
MostAwesomeDude: otaylor: Hm. Strange.
otaylor: What's strange about it?
cbmuser: hi, anyone can point me to the proper git-repos for drm and xorg for radeon with modesetting ?
otaylor: What it's telling me is that it dumps a whole bunch of commands into the gpu, then the gpu takes a long time to process them
MostAwesomeDude: otaylor: Well, there's no serious overhead in the r300_dri or syscall layers?
otaylor: MostAwesomeDude: there's overhead, but it's not the limiting factor - reducing CPU there doesn't improve throughput
otaylor: (While doing an animation, we use about 20% cpu to peg the gpu)
MostAwesomeDude: otaylor: So it *is* in the GPU setup, then. :C
MostAwesomeDude: Hm. Kind of not sure how the best way to proceed might be. Maybe glFinish() at every glFlush() and see if one stands out?
MostAwesomeDude: Sinuvoid: You'll need Mesa 7.4 for your profile to be useful at all. :/
MostAwesomeDude: is trying to think of a useful way to do this
otaylor: MostAwesomeDude: mesa may be sending really bad commadn buffers that repeatedly establish state, etc. Clutter may be doing really stupid stuff. We may have all the interesting textures in AGP space, and be throttled on AGP bandwidth (only 1GB/s on my card)
MostAwesomeDude: otaylor: Oh, using Clutter. Hm.
Sinuvoid: so
Sinuvoid: I need to install new Mesa?
otaylor: There's various ideas I have for getting clarity - one basic thing is just improving the stuff that radeon-gem puts into debugfs so I can see what's where
MostAwesomeDude: otaylor: Are you on a CS-enabled Mesa?
MostAwesomeDude: It could be very useful to have dumps of the CS that are submitted.
otaylor: MostAwesomeDude: Of course. (This is radeon-rewrite/dri2/kms)
MostAwesomeDude: otaylor: Ah. We can look for bad/suboptimal submissions.
Sinuvoid: MostAwesomeDude: I need to install the new Mesa, right?
otaylor: Instrumenting the drm to allow dropping breadcrumbs into the command screen and measuring their completion time could be generally useful
otaylor: stream
MostAwesomeDude: Sinuvoid: Yeah, that'd probably be good.
MostAwesomeDude: otaylor: That *would* be useful. The problem lies in figuring out where that's possible.
otaylor: MostAwesomeDude: the breadcrumbs stuff is definitely possible, since we already do almost exactly that for glFinish()
MostAwesomeDude: agd5f: ^^ Any ideas on how we could watch the RB like that?
otaylor: MostAwesomeDude: krh is working on some stuff for letting an app read events back off the drm fd, so that could be a mechanism for returning timestamped breadcrumbs to userspace
MostAwesomeDude: Well, without the card's help, I can't really see how we could do it at any point besides during draws.
MostAwesomeDude: i.e. after every pkt3.
MostAwesomeDude: But maybe that would be enough.
otaylor: MostAwesomeDude: Well, if you control the generation of breadcrumb points from userspace, then mesa can just split command buffers as necessary
suokko: MostAwesomeDude: At least in Jesse's kernel is ring buffer dumping interface in debugfs
MostAwesomeDude: suokko: Jesse? jbarnes?
suokko: glisse
MostAwesomeDude: Ah. (FYI he's Jerome, not Jesse. :3 )
suokko: sorry
otaylor: MostAwesomeDude: beyond the breadcrumbs, the other thing that's interesting is to try and estimate memory bandwidth. It's a little tricky because the kernel or even mesa has no idea of how much any texturing operation is going to read
MostAwesomeDude: otaylor: Well, once the texture's over in cardspace, reads are negligible in time, mostly.
MostAwesomeDude: So it's only a matter of seeing how much time it takes for the texture to migrate.
otaylor: MostAwesomeDude: But if there was some sort of mesa_gem_get_texture_domain() call, doing it at the app level is possible
otaylor: MostAwesomeDude: yeah, assume vram bandwidth as infinite isn't a bad first impression. I'm interested in the limiting case of a 64-meg r300 at the moment, so textures in agp space are pretty interesting to me.
otaylor: (I think there are also flaws in the migration logic so even if you have a 512meg card, some buffers will get stuck in TT space permanently. But not completely sure about tahat.)
suokko: feels that fbcon should have accelerated text drawing
agd5f: otaylor: we don't use more than 256 MB of vram yet I don't think
nanonyme: Even if memory manager is present? :/
otaylor: agd5f: 256MB sounds a lot like infinity to me :-)
agd5f: MostAwesomeDude: you can insert a timestamp write or a interrupt into the command stream
ajax: we're limited by the bar size, yeah
ajax: mildly lame.
agd5f: nanonyme: should be possible to use it all with a memory manager, just not there yet
nanonyme: Right.
MostAwesomeDude: agd5f: Yeah, I was thinking about IRQs, but if there's a way to write timestamps, that would work even better IMO.
nanonyme: Gods, no. >.< http://www.phoronix.com/forums/showthread.php?t=16975
nanonyme: Yet one more place in your computer to do (usually) unnecessary upgrades for which might break your hardware. \o/
nanonyme: (At least we know now where Luc Verhaegen ended up :p)
soreau: Not to mention make for a support session nightmare
nanonyme: blames Novell
MostAwesomeDude: nanonyme: Luc's still in here...
nanonyme: MostAwesomeDude: Right. Well, doesn't change my opinion that while that's probably very skilled programming it took, giving BIOS flashing tools for endusers is always a risk, especially if they believe that they get the device to work better by flashing another device's BIOS on it.
nanonyme: This *will* break a lot of devices, it's not just a possibility.
dmb: i'm guessing there is no recovery method to a botched vbios :D
ajax: sure there is
chithead: actually it is easier, just stick in a pci video card
nanonyme: :P
ajax: boot with two cards in, set the one that works to primary, flash the other one
suokko: or ssh to there and flash old bios back :)
nanonyme: suokko: Might not work.
nanonyme: ajax's way does.
suokko: Why wouldn't computer boot with "broken" graphics card?
nanonyme: They usually don't, actually.
nanonyme: At least with normal BIOS settings.
nanonyme: Hangs in POST.
mimikry: but after disabling it it shoudl work
suokko: So you are saing that if I remove card from my headless compiler farm machine it won't boot ... I have to test :)
nanonyme: suokko: Not really.
MostAwesomeDude: But, more importantly, I'm left wondering *why* it would be needed. AFAIK we're not like GeForce/Quadro where the BIOS determines the chipset caps.
MostAwesomeDude: Radeon/FireGL is actually set up with the same driver, but FireGL is just much higher-performing. I think.
nanonyme: MostAwesomeDude: Default powersaving options differ between BIOS'es.
nanonyme: Afaik.
nanonyme: You might get the card to run cooler if you flash in a BIOS from another card. (likely from a laptop one)
nanonyme: That's the only reason I've thus far heard for flashing those.
nanonyme: ponders when we get the first laptop users flashing BIOS's on their integrated chips
otaylor: MostAwesomeDude: the placebo effect is a really powerful thing
nanonyme: It's not really like they can just put in another graphics card.
MostAwesomeDude: otaylor: No kidding.
agd5f: plus it's possible different boards use different fan controllers or thermal chips, so you might end up with no cooling
MostAwesomeDude: Or HCF.
agd5f: MostAwesomeDude: timestamps are just a value written to a scratch register
nanonyme: sighs
MostAwesomeDude: agd5f: Not seeing it in the r5xx pkt3 list; is this part of the r2xx docs that just never got redocumented?
nanonyme: Sorry, shouldn't have started a rant, I get annoyed too easily.
spstarr: ajax: how goes switchable graphics?
agd5f: MostAwesomeDude: just use a packet 0 and write to a cp scratch register
agd5f: MostAwesomeDude: we already do it for the dma buffer pool
MostAwesomeDude: agd5f: Ooooh.
MostAwesomeDude: Couldn't do this in userspace (without massive hax), but I suppose this could be tapped quickly into DRM.
otaylor: agd5f: there's some way of getting notification when the operation finishes at the CB too, right?
MostAwesomeDude: [drm] [radeon] Took 1ms to render etc....
agd5f: otaylor: yeah
agd5f: you can set it up so that the CB signals when it's done
agd5f: otaylor: see section 4.9 in the r5xx programming guide
ajax: spstarr: hah.
zhasha: spstarr, switchable graphics as in having 2 gpus?
agd5f: otaylor: r6xx/r7xx are much nicer in that you can generate events for tons of stuff. see the EVENT_WRITE* packets
spstarr: ajax: i guess that means no ;-)
ajavid: hello guys
ajavid: debian + x1900xt + radeon in 7.4 Xorg
ajavid: HannsG HG 216D monitor
ajavid: 22" LCD
ajavid: When I use DSUB cable, I get 1680x1050@60
ajavid: When I use HDMI cable via a DVI adapter, I get http://paste.debian.net/36074/
ajavid: and only that
ajavid: here is my xorg.conf
ajavid: sudo dpkg-reconfigure xserver-xorg (generate a new blank one, with 100% Xorg autoconfigure) to start clean
ajavid: here is my Xorg log file
ajavid: http://paste.debian.net/36075/
ajavid: Please advise
agd5f: ajavid: it's not able to get an edid when using the DVI adapter
ajavid: I see
ajavid: How can I fix this?
agd5f: ajavid: try a different adapter, or manually force the mode you want
ajavid: I see
ajavid: agd5f, you mean to say 'different dvi port' ?
ajavid: (only 2 are available)
agd5f: you said you were using dvi to hdmi adapter
ajavid: ahh yes
agd5f: some adapters are crappy and don't connect all the pins, etc.
ajavid: my monitor only accepts HDMI and VGA
agd5f: you could try the other dvi port
ajavid: my gfx card only provides two dvi ports
ajavid: agd5f, I ordered top of the line from newegg
ajavid: 12$ (usually they are 6$)
ajavid: also, when I take out the cable, and put it in a diff port, and I get no more input signal on monitor
ajavid: if I plugin back to the old port, I still get no input signal on monitor
ajavid: so once I take out the cable from the gfx card, I have to restart the system, I can't for the life of me get the monitor turned back on
agd5f: could try and restart X rather than rebooting
ajavid: ok
ajavid: good idea
ajavid: nope, that didn't do anything either
ajavid: its a brand new plug too
ajavid: agd5f, so you think its a hardware problem?
agd5f: ajavid: seems like it. if it can get an edid via the vga then the i2c stuff would appear to be working correctly
agd5f: ajavid: maybe make sure the tv is in hdmi mode before trying it
agd5f: or maybe your tv doesn't provide an edid
ajavid: oh
ajavid: yeh, let me check
ajavid: nope, menu says input setting is on HDMI (which is blue) and Analog is grey
ajavid: so I guess hdmi is on
ajavid: btw
ajavid: I had no idea of all the options in radeon
ajavid: I did Xorg -configure and I got a long list of Device section options for the radeon driver
ajavid: where do you guys keep a list of what these options are and what they do?
ajavid: agd5f, manual override does work
ajavid: agd5f, before in the past, it used to say DVI-0 or DVI-1 connectd and one disconnected
ajavid: now it says both DVI ports disconnected (via xrandr -q)
ajavid: DVI-0 disconnected (normal left inverted right x axis y axis) 1680x1050 (0x4d) 146.2MHz
agd5f: ajavid: http://wiki.debian.org/XStrikeForce/HowToRandR12
ajavid: hm
ajavid: i'll read it, again.
ajavid: what exactly am I looking for here?
agd5f: ajavid: you'll probably have to force the DVI port to digital mode as well: xrandr --output DVI-0 --set dvi_monitor_type digital
ajavid: the reason I switched to DVI was because my fonts looked bad in vga mode
ajavid: now in digital, they look even worse (tiny rgb pixels in the corners/rounds of the fonts
ajavid: they said digital will improve sub pixel font rendering
ajavid: *sigh*
ajavid: agd5f, anything else you can advise?
ajavid: 07:14 < agd5f> or maybe your tv doesn't provide an edid
agd5f: ajavid: you could adjust the subpixel mode, but I'm not sure how you do that. also check you tv. some have options about how they display the image (scaling, overscan, etc.)
ajavid: it does, it used to, I've ran this on dvi for a while an on autoconfigure
agd5f: ajavid: maybe adapter then
ajavid: its a LCD monitor
ajavid: not a TV
agd5f: oh, ok
ajavid: agd5f, what do you mean apdapter?
agd5f: onlyhas hdmi though?
ajavid: it has hdmi + vga only
ajavid: its hannsg hg 216d hdmi
ajavid: its a HD monitor
ajavid: I guess / tv too, you can hook it up to ps3 or anything with hdmi output
ajavid: agd5f, the best mode is horizontal rgb
ajavid: which is currently turned on
ajavid: (for sub pixel rendering)
Sinuvoid: MostAwesomeDude: How do I profile
MostAwesomeDude: Sinuvoid: oprofile or another system profiler.
Sinuvoid: What type of data do you want?
MostAwesomeDude: Anything in r300_dri that's called lots of times, or that takes a very long time.
MostAwesomeDude: Anything that is called a lot and takes a long time is ideal. :3
rainbyte: hi
MostAwesomeDude: Hm. gears, arbfplight, glutfx, all do the microgears thing.
MostAwesomeDude: Ack, wrong channel.
Sinuvoid: MostAwesomeDude: Is it hard writting drivers?
MostAwesomeDude: Sinuvoid: Kind of.
MostAwesomeDude: You need patience. You also need to know C.
Sinuvoid: Alright, I know C
Sinuvoid: (Well, still need to learn wtf a enum is :S)
spstarr: enumeration?
spstarr: :)
spstarr: enum myEnums { foo = 1, bar, goo, boo };
spstarr: printf("myEnums.foo = %d\n", myEnums.foo);
spstarr: myEnums.foo = 1
Sinuvoid: I dont get it
Sinuvoid: What're they for?
Sinuvoid: spstarr: what do I need to know to make drivers?
Sinuvoid: Or gfx drivers
agd5f: Sinuvoid: an itch to scratch. find a bug or feature and just start looking at the driver and asking questions
Sinuvoid: agd5f, I want it to have better 3D supoort
Sinuvoid: support*
Sinuvoid: for r400
agd5f: Sinuvoid: start reading the 3d driver and asking questions
agd5f: chang bits, recompile and see how things change
agd5f: *change
Sinuvoid: dri is the driver, right?
spstarr: agd5f: maybe compile those questions into wiki info then you wont have to hear people asking them over and over? :)
agd5f: spstarr: feel free :)
Sinuvoid: dri is the driver, right?
spstarr: agd5f: I'd rather be asking them :)
spstarr: but not yet... im unemployed right now and fixing that is priority #1
Sinuvoid: Hello?
yangman: Sinuvoid: 3D is in mesa
Sinuvoid: For R300 - R500?
yangman: all of them
Sinuvoid: >_>
Sinuvoid: Should it be able to run Ut2004 pretty well?
osiris__: new patch-set for radeon-rewrite on mesa3d-dev. please review and test
Sinuvoid: >_>
Sinuvoid: Does Radeon-Rewrite help with the 3D stuff
agd5f: Sinuvoid: yes
agd5f: it's a partial rewrite of the 3d drivers
Sinuvoid: How do I install it/Where can I find it
agd5f: Sinuvoid: http://cgit.freedesktop.org/mesa/mesa/?h=radeon-rewrite
agd5f: not sure if it will help your ut peformance though. need to find out what the problem is first
ajavid: agd5f, I improved it a lot by lowering the sharpening feature of my monitor
ajavid: agd5f, it was on 50%, I lowered it to 25% (factory default is 50%)
Sinuvoid: Where's the download link
ajavid: agd5f, the fonts look slightly better, but anything lower than 25% gives me blurry picture
agd5f: IIRC, ut used some special vertex buffer format that was slow in mesa, like it had to convert from short to float and back to short or something like that
Sinuvoid: This git stuff causes mega confusion
Sinuvoid: agd5f: why not implement it then?
agd5f: Sinuvoid: at the time it was an infrastructural issue in mesa that was a lot of work to fix, but it was a while ago
Sinuvoid: Want to be the first person to do it? :D
mattst88: agd5f, any clues wrt "(EE) AIGLX error: Calling driver entry point failed"?
mattst88: using glisse's KMS stuff, libdrm modesetting-gem, radeon-rewrite, et al
agd5f: mattst88: probably something built against old headers
mattst88: ah, good suggestion. I'll check that
mattst88: agd5f, yes, I had something compiled against the wrong version of something else.
mattst88: thanks for the help :)