Luzipher: hah, found the r600g repository :)
airlied: once we have more things stable I suspect we can do more optimising on r600
Luzipher: ahh, there are repositories from all of you ... *drools*
Vash63: I was kind of worried EXA wouldn't get optimized anymore since Gallium is eventually supposed to do it anyway.
airlied: Vash63: Gallium sites below EXA
airlied: sits below EXA even, at least it does so far
Vash63: I thought I heard something about an EXA state tracker for Gallium?
Vash63: Not that it's really necessary with every driver doing it well anyway.
airlied: you missed what a state tracker was
Vash63: I guess so.
airlied: it just sits where the driver does now
airlied: so there is EXA code in the server and in the driver
airlied: the server code is probably where most things are that need work
yupi: hi, i have a problem with multiple cards setup. machine hangs whenever i try to switch to vt, reboot it or somehow exit the X. i'm using 2.6.30 kernel with latest radeon driver. any hints?
yupi: xserver 1.6.5
roy_hobbs: Hey, I'm having trouble *initiating* suspend with KMS enabled. I hear something happen in the computer - like the hard drives power down or something - but the monitor/backlight stays on, and the computer does not actually suspend.
soreau: yupi: AFAIK, multi card setups are not supported yet
soreau: Though some(TM) have said 'system-config-display --reconfig' might generate a multi-card conf
soreau: on fedora
soreau: roy_hobbs: I have the same issue
soreau: I haven't heard of a fix yet.
MostAwesomeDude: I know no reason why multicard would not work.
MostAwesomeDude: That said, I haven't actually tested yet.
MostAwesomeDude: And KMS+DRI2 only.
roy_hobbs: soreau: so do you just disable KMS?
MostAwesomeDude: Vash63: Oh, Exherbo, that'd be why.
soreau: roy_hobbs: No, I don't use s/r
Vash63: Yeah, I don't think stability or usefulness was a consideration when they added it.
soreau: roy_hobbs: You might want to look for similar bug reports or file one about it if none exist yet
yupi: multicard works fine
dmb: Luzipher, yes, i do have a displayport card
dmb: just not a displayport monitor
yupi: it just hangs on X exit
roy_hobbs: Ok, but while I'm here: On another computer, with a different ATI card, I'm having a problem where *some* of the time when resuming from suspend, the screen remains black, but the mouse cursor is visible/responsive, it even changes cursors when it moves over what should be a button/etc
MostAwesomeDude: Vash63: Exherbo is one of those distros that doesn't talk to upstreams. We have no idea what they're up to and we don't see bug reports from them.
roy_hobbs: This computer DOESN'T have KMS enabled, because with it enabled, the screen goes black early in the boot process - but that's another issue =)
Vash63: Heh. I just installed it, coming from Gentoo. So far I like it but given its nature I'm not surprised that they added some options that aren't yet usable. Anyway, if the EXA code is slow due to server side stuff, does that happen on other drivers with KMS enabled also? Specifically Firefox is the worst.
Luzipher: dmb: hmm, i have the monitor, not the card ;)
dmb: Luzipher, what kind of monitor?
dmb: Luzipher, i have a radeon 5770
dmb: not that badly priced
MostAwesomeDude: To get Fx to not be slow, turn off smooth scrolling.
Luzipher: dmb: HP LP2475w
MostAwesomeDude: That's it.
MostAwesomeDude: Also, NSAPI plugins can be slow, especially Java and Flash.
dmb: flash sucks bigtime
Vash63: I have smooth scrolling off.
dmb: make sure you turn on force gpu for flash
Vash63: It's still noticeably laggier than scrolling in Chromium.
dmb: if using radeon driver
MostAwesomeDude: Do you have DRI enabled?
dmb: Luzipher, expensive monitor
Vash63: Yes.
Vash63: Compositing and opengl work well.
dmb: honestly, with radeon driver, firefox performs well for me
dmb: even with smooth scrolling
DanaG: longs for the day when there's power savings + KMS on R600.
Vash63: What card? KMS?
DanaG: Performance is secondary to fan noise and such, for me. Especially on a laptop.
dmb: Vash63, laptop?
dmb: eern
dmb: meant DanaG
Luzipher: dmb: yes ... especially because it probably not really much better than a TN+Film Panel which would be a lot cheaper
Luzipher: dmb: but I couldn't check it in action before buying ... had to rely on reviews ...
DanaG: http://www.bit-tech.net/hardware/monitors/2009/07/28/hp-lp2475w-24in-widescreen-tft-review/1
dmb: i'm looking for a nice cheap 20 inch with displayport :P
DanaG: wishes somebody would make a 120dpi desktop LCD. Or 147, as my laptop is.
DanaG: "The first batch of LP2474w shipped with S-IPS panels, but since then HP has fitted an H-IPS panel, which generally gives more accurate colours the tried and tested PVA and much better contrast and image quality than TN panels."
Vash63: On a complex page with the window fairly large (est. 1200x1000) it seems to take like 100ms per screen update when scrolling up and down.
DanaG: 95dpi... bleh.
Luzipher: DanaG: yes, I bought it because of the S-IPS Panel ... I really don't like the TN panels from what I saw in a shop ... and IPS Panels are rare to nonexistant in 24" it seems
DanaG: My laptop has a TN, of course.
Luzipher: err, PVA Panels
DanaG: er, what word are you changing to "PVA"?
DanaG: I just wish somebody would make a friggin' high-res desktop display.
Luzipher: the last IPS ;)
Luzipher: yeah, that'd be nice ... but oh well ... quality isn't important anymore nowadays, it seems
Luzipher: but it
Vash63: I have a brand new HP desktop display that's IPS.
Luzipher: bt it's interesting that they changed from S-IPS to H-IPS ... I have to check what that means exactly ...
Vash63: It's a 24" too.
Luzipher: Vash63: do you have the product name ?
Vash63: LP2475w
Luzipher: so it's the same as mine ;)
Pallokala: I have S-IPS and a really lame TN next to each other and the difference in image quality is stunning
Luzipher: well, the only real problem i have with it is, that if you look at a website with white background maximized, you get a tiny hint of greenishness on the left and a tiny hint of redishness at the right side ... i eventually got accustumed to that, but it was irritating at first
Luzipher: hmm, gotta love it when they change the hardware but not the prudict name ... would be interesting if mine is S-IPS or H-IPS ...
Pallokala: Luzipher: then don't buy Dell ;)
Vash63: The worst is Samsung.
Vash63: Half their panels are Samsung.
Vash63: They get cheap panels from other brands sometimes.
Vash63: And use them in the same model.
Pallokala: My 2007fp has S-IPS, some earlier versions of the display had PVA
dmb: yeah, do they sell 1920x1200 desktop monitors anymore?
dmb: i used to have a 1920x1200 laptop monitor
dmb: was quite nice
Vash63: The one I just mentioned.
Vash63: HP 2475w
Vash63: Er, lp2475w
Luzipher: Pallokala: it's a HP :)
DanaG: They do make desktops... but not high-dpi ones.
Pallokala: Luzipher: yes, I just wanted to warn you
Luzipher: hm, "Manufactured May 2009" ... so it should be the new one with H-IPS ... *cheers*
Luzipher: Pallokala: ah ok, thanks :) ... well, I hope I don't need a new monitor that fast ;) (my old was a nice Samsung 21" 4:3 thingy ... but it more or less died after 3 years ... i really liked it (was PVA))
Nightwulf|work: hi all
glisse: airlied: any idea why s-video would report having one mode but just give a null ptr with kms ?
airlied: glisse: no idea, is it rs480? if so we should just disable tv-out ;-)
airlied: where is the null ptr coming from
airlied: ?
glisse: yup, sadly mine doesn't have one i will go over the code again
glisse: in drm_modedisplay the null come from a call to libdrm mode stuff
glisse: libdrm says that there is one mode but the ptr it gives is null
airlied: oh wierd
glisse: well not that weird kms report setting a mode on tv-out
glisse: but Cai said that there is nothings connected their
glisse: so i guess the weirdness is in kernel
airlied: whats the bug?
glisse: https://bugzilla.redhat.com/show_bug.cgi?id=531383
glisse: see dmesg and hacked xorg log
airlied: I wonder if we have a problem with 0 or 1 mode in drm_mode_getconnector
glisse: yeah i will go over the code
airlied: I think rs480 dac load detection is broken for tv
glisse: btw any progress with EruditeHermit s/r issue ?
glisse: maybe we can disable load detection on tv
glisse: and ask people wanting tv out to explicitly force output :)
airlied: glisse: might have to implement legacy spread spectrum
glisse: tv out should die ;)
airlied: no idea if it'll help
airlied: glisse: tv load detect works on nearly all my cards
airlied: so I think just disable it for rs480
airlied: glisse: I tested with every r100->r600 I had
airlied: glisse: on my laptop though we don't get spread spectrum enabled on resume
airlied: but the bios enables it on boot
glisse: will look at the code first and if i can't find anythings then i will disable it
airlied: so I think I need to save/restore the SS stuff or get AMD to tell me how to program it
airlied: is there a dmesg with higher deubg?
glisse: no i forget to ask for it
airlied: radeon.tv=0 should ignore tv
airlied: but I've not really tested it
aszlig: moin
glisse: airlied: btw m10 vbetool post output of Eru is weird
glisse: is vbetool broken ?
airlied: glisse: no it all looks okay to me, the vbetool hacks can actually decode to radeon reg read/write
airlied: if you tell it the io port index/data pair
airlied: so I fixed that for him and added some more in/outs
airlied: I've found the aisc init tables
airlied: however the SS setup happens before then
airlied: radeonfb has code for s/r on those chips though so I can rip it off I think
glisse: well looking at the trace i don't see much reg written
glisse: a lot of access to vram thought
airlied: look at OUTREG(
glisse: oh so this vbetool directly decode the register access
glisse: mine doesn't
glisse: and i run the output to a tools after
airlied: glisse: your one does if you read the code ;-)
aszlig: hm, do you have any idea about how to best debug a blank screen without any errors in the logs and without the possibility to ssh into the machine? ;-)
glisse: likely benh code in radeonfb
airlied: glisse: have a look at thunk.c
airlied: it defines two PORTs
glisse: airlied: yeah i might have commented that at one point
airlied: no it doesn't work unless you set it up by hand
airlied: sicne the i/o ports move on different macinh
glisse: yeah i know i do that in my tool
airlied: I meant to make it autodect from pci
glisse: btw there is an interesting comment on the t60 x1400 s/r issue
glisse: it seems that resuming with a laptop unplugged works
glisse: not always but most of the times
airlied: yeah I think it might be powering down some bits
airlied: looking at radeonfb it explicitly turns off lots of hw before setting D3
glisse: i think benh got a lot of info from ati back in the days
airlied: lots of it is ER from apple
airlied: RE even
glisse: so it might make sense to reproduce what he did :)
glisse: at least for r3xx/r4xx era
airlied: I'm trying to find the bits that are different from the bios init scripts
airlied: but the reason I think battery/plugged or unplugged maaters
airlied: is something has residual state when we restore
twnqx: glisse: in case you'r interested
glisse: what i do is that i gather a list of reg vbetool write/read and then dump them
airlied: and gets confused so needs a better reset
twnqx: i can see that my t500 here definitely changes speeds on the radeon between plugging/unplugging the AC
glisse: airlied: yup likely that
twnqx: so the bios does *things* here :P
hnsr: meh, anongit down atm? I keep getting "anongit.freedesktop.org[0: 131.252.210.176]: errno=Connection timed out" when trying to clone
hnsr: no actually, that might be my firewall
hnsr: now it really does seem down.. oh well
hoo-hah: hi guys. I've got a question. is it okay to revert back to stable 2D support for my hd4850, though I still want xv output. I tried disabling KMS, thinking that would prevent my libdrm/mesa/xf86-drivers-ati (all from git) from trying to enhance 3d performance
hoo-hah: basically, I want my 2d performance to be as fast as possible (I've been noticing some lag with rxvt-unicode upon refreshing)
hoo-hah: but I still would like to be able to use xv-out with mplayer
hoo-hah: will this adversely affect flash video, by any chance?
hoo-hah: this is my current xorg.conf http://dpaste.com/118610/
legume: airlied: glisse: I still get an oops with tv=0 as noted - http://bugs.freedesktop.org/show_bug.cgi?id=24150
legume: airlied: glisse: Slight difference in trace now - http://www.pastebin.ca/1664766
hnsr: not sure if anyone cares but i set up a temporary mirror cgit interface at http://cgit.aphax.nl/mesa , since the one on fdo seems kind of borked
POTHEAD`: Hello :)
zhasha: POTHEAD`: hi
POTHEAD`: whats up guys?
POTHEAD`: :)
zhasha: nothing much, do you have a problem?
POTHEAD`: not problem
POTHEAD`: but i wonder
POTHEAD`: how can i buff up my RADEON 1650x pro
POTHEAD`: :)
POTHEAD`: i play world of warcraft, and i have only 20 fps ~
POTHEAD`: :(
zhasha: you can either use a fairly old Xserver and kernel + fglrx
zhasha: but that will create a ****nami of problems for you
POTHEAD`: oh then i dont need it
POTHEAD`: :D
POTHEAD`: dont want problems
POTHEAD`: :)
glisse: POTHEAD`: we are not yet addressing the performances issue
POTHEAD`: ok mate :)
zhasha: MostAwesomeDude and a couple of others are working on a radeon gallium driver that will eventually perform well
POTHEAD`: good :)
zhasha: but currently we're struggling just to get it working so not much performance work just yet
glisse: we are still focussing on fixing major bug (suspend,resume,black screen, ...) hiting limited range of hw
zhasha: sadly, foss drivers have been in an abysmal state :/
zhasha: for linux gaming, especially with wine, the best option is to go with proprietary nvidia
zhasha: or r600+ proprietary radeons (though I haven't tested that myself)
Ghworg: The open drivers are doing suprisingly well with wine for me, only major thing missing is glsl.
Ghworg: Once that is in there I think they'll do better than fglrx, which sucks for wine
Ghworg: Although compressed textures not working (bug 24047) is killing me as that makes my fav game KotOR unplayable
adamk: compressed textures haven't worked properly for any driver above r200, actually.
adamk: On r300 it doesn't work for games that use multitexturing. On r600 it's broken altogether. This really is something that needs to be addressed.
legume: Ghworg: Try making ~/.drirc like http://www.pastebin.ca/1664909
adamk: Unless I'm missing something, all that does is disable s3tc support, so that the games don't use compressed textures.
legume: adamk: Yes - which means you don't get a screen full of garbage or have to edit (if you can) the individual game configs.
adamk: Right... But that's not really a solution :-) Quite a few games won't play at all if s3tc isn't available.
agd5f: glisse, airlied: most (all?) of the reg accesses in the bios tend to go through 0x0/0x4. plus a lot of 8 bit accesses.
glisse: agd5f: yeah know that
glisse: it's just that i disabled decoding in my vbetool and did it through an helper prog
legume: adamk: true - I meant it as a workaround that should at least get some working now or save time looking up cvars.
Ghworg: legume: Disabling them completely just gives me no textures at all unfortunately
legume: Ghworg: Ahh OK.
Ghworg: I found an app that decompresses textures outside the game, designed for neverwinter nights. Unforunately while the file formats appear to be the same as KotOR it doesn't work for it
adamk: What app is that?
Ghworg: adamk: http://nwvault.ign.com/View.php?view=Other.Detail&id=577
adamk: Interesting...
adamk: That's not really necessary on most cards these days, though. Even the open source drivers support s3tc via: http://homepage.hispeed.ch/rscheidegger/dri_experimental/s3tc_index.html
Ghworg: adamk: Wait there is a newer version, http://nwvault.ign.com/View.php?view=Other.Detail&id=847 (that ver still doesn't work for me though)
adamk: Of course, as I said, it doesn't work for apps that use multitexturing on r300, and doesn't work at all on r600 :-)
taiu: agd5f: what's the num_indices > 0xffff separation in r600 draw path supposed to help?
agd5f: taiu: 32 vs. 16 bit
taiu: yes, but why
agd5f: if there are more than 0xffff indices, you need to use 32 bit
taiu: afaik it will never fit, we'll have only 64k bytes cmd buffer
agd5f: oh, right
taiu: aa, ok
agd5f: taiu: we should probably fail if we have more indices than cmd buffer
agd5f: or figure out what index_auto doesn't work with an offset for some people
taiu: that would be good, but my card worked ok,
agd5f: taiu: yeah, mine did too.
glisse: why not fetch indices from a bo
agd5f: glisse: we do for the ib case
taiu: idx_offset was also ins some state atom, maybe it does'nt like emitting it twice, or maybe it needs some other register written between it and draw initiator
agd5f: taiu: yeah, I tried messing with that
agd5f: weird thing is, it only seemed to be a problem with dri1
agd5f: with dri2 it worked on all cards I have
taiu: hmm, weird indeed
Ghworg: Bah, just make everyone upgrade to dri2. Problem solved ;-)
adamk: Not everyone can upgrade to DRI2 :-)
hnsr: at last, damn power supply just died :|
[Enrico]: guys i'm on r600 3d, let me congrats, awasome work
[Enrico]: thanks you all very very much
[Enrico]: just a little question. i tested it with radeon driver built as module (gentoo here) and when it is loaded tty res isn't changes. should i compile it builtin ?
agd5f: [Enrico]: you need kms for hi-res console
tormod: [Enrico], you just have to enable KMS with radeon.modeset=1
[Enrico]: agd5f: well i must have it lol
[Enrico]: agd5f: but how can i check ?
agd5f: [Enrico]: check dmesg
[Enrico]: oh so i have to specify radeon.modeset=1, it isn't enabled by default
tormod: [Enrico], depends on your kernel conf
[Enrico]: tormod: i have zen-sources .31 zen7 + drm-next
[Enrico]: agd5f: this is the only intresting line [drm] radeon defaulting to userspace modesetting.
[Enrico]: so i guess i must pass radeon.modeset=1
agd5f: yup
[Enrico]: but let me review also my kernel config to check if i can set it to default
adamk: You can in the staging section in Device Drivers.
[Enrico]: agd5f: eheh i didn't enabled staging driver.... shame on me!!!
[Enrico]: agd5f: well i guess it is easy to make some mistake when you make a migration like fglrx -> git radeon eheheheh
hnsr: :D
[Enrico]: indeed if this will work good for a little time i will just build radeon builtin :D
adamk: KMS has finally gotten to the point were I can enable it by default these days and have X work properly. I was quite happy when I discovered this yesterday.
adamk: My only remaining issue with it is that KMS can't drive my CRT at 1600x1200 without major flickering.
[Enrico]: agd5f: kms up and running now :D
agd5f: [Enrico]: cool
[Enrico]: agd5f: you can say that!
[Enrico]: guys many many thanks!
[Enrico]: this driver seems to be really well done!
[Enrico]: oh btw i know there is no complete powermanagement already, but it is possible to force fixed lowpowermode isn't it? how?
agd5f: [Enrico]: not with kms
glisse: adamk: you did open a bug about that ?
[Enrico]: agd5f: oh ok :D
[Enrico]: agd5f: well anyway my video card has no fan (laptop here eheh) so i don't care very much
[Enrico]: i will just wait for powermanagement code to be usable :D
pocek: :q
pocek: oops...
glisse: agd5f: do you remember why load detection for legacy dac is different btw kms & ddx ?
agd5f: glisse: shouldn't be
agd5f: we disabled load detection on legacy tv dac in ddx since we tended to get false positives
agd5f: between tv and vga
glisse: it seems there is 3 different dac detect in ddx
Zajec: hey guys, i've problem with my own kms downclocking. i've created
Zajec: void radeon_pm_reclock(unsigned long arg);
Zajec: when I call it manually from "radeon_debugfs_pm_info" then it works fine
Zajec: but when i start a timer inside "radeon_debugfs_pm_info" with 50ms delay, i get lock up on executing AtomBIOS command
Zajec: when this timer fires
Zajec: do you have any explaination for this?
glisse: Zajec: never do such things from a debugfs callback
glisse: also you need the radeon_device *rdev struct to be passed to your funciton
Zajec: glisse: it's very hacky, but just for testing
glisse: all reg access need the rdev struct
Zajec: glisse: i pass it, i can read it parameters without a problem
Zajec: glisse: i can even call functions on passed rdev
Zajec: glisse: just AtomBIOS engine set command locks up
glisse: changing gpu clock need to idle the engine
glisse: so you need to take control
glisse: take cp lock
glisse: wait for idle
Zajec: glisse: do you know which engine?
Zajec: idle of... sth specific?
glisse: and than change clock
glisse: idle of all the gpu
Zajec: ah
Zajec: i thought setting engine clock is safe witout idle
Zajec: ok, thanks
stikonas: with latest git on R600 nexuiz crashes with the following error:
stikonas: [12095.231807] [drm:radeon_cs_parser_init] *ERROR* cs IB too big: 16393
stikonas: [12095.231811] [drm:radeon_cs_ioctl] *ERROR* Failed to initialize parser !
stikonas: any ideas why this happens?
glisse: because cs ib is too big :)
dmb: whats a cs ib?
glisse: cs=command stream, ib=indirect buffer
glisse: we limit the size of indirect buffer and all command stream need to fit in an indirect buffer
glisse: 64K is the limit of 16394dwords
glisse: bug is in userspace
dmb: oh
glisse: it should flush before having too big cs
dmb: userspace as in mesa?
dmb: or userspace as in the app
glisse: mesa
dmb: oh
glisse: app doesn't know about ib
glisse: or cs
glisse: this is hw specific
glisse: it's in the driver
dmb: i'd hope not :)
MostAwesomeDude: glisse: 64k always? i can set that for good in gallium.
glisse: MostAwesomeDude: yeah always because ib pool has 64k buffer iirc
MostAwesomeDude: glisse: alright, thanks
zhasha: MostAwesomeDude: look at phoronix and tell me WHAT HAVE YOU DONE?!
taiu2: maybe r600 has more, it has: Indirect Buffer Size [19:2]
glisse: taiu2: it's not hw restriction
glisse: it somethings we decided in the kernek
glisse: well i did choose this limit
taiu2: yep, i know
taiu2: i thought r300 had alos hw limit on this - maybe not then
glisse: yeah there is a limit but it's lot bigger than 64k iirc
DanaG: http://www.matrox.com/graphics/en/press/releases/2009/process_control/mission_critical/mseries_octal/
DanaG: interesting... wonder if it's open-source, and how it'll compare to EyeFinity.
AstralStorm: hello
AstralStorm: seems fragment shader support disappeared
AstralStorm: and it worked fine here (fine enough for mplayer)
AstralStorm: at least mplayer says so
zhasha: AstralStorm: we never had fragment shader support, we do have fragment program support though
AstralStorm: as in ARB_fragment_program?
zhasha: yes
AstralStorm: it doesn't work now for one reason or another
AstralStorm: at least mplayer says so
AstralStorm: it did work before
zhasha: does it appear in your extension list?
AstralStorm: I'll dig into it some more
AstralStorm: that unsharp mask scaler is just too good to not have
AstralStorm: (plus hardware yuv conversion)
AstralStorm: zhasha: grepping glx info tells so
AstralStorm: http://dpaste.com/118757/ - glxinfo
adamk: So what makes you think that it doesn't work now? :-)
AstralStorm: adamk: "error compiling shader program"
AstralStorm: let me paste some mplayer verbosity for you
AstralStorm: http://dpaste.com/118759/
AstralStorm: it has worked before and is not tied to mplayer or mesa version it seems, hmm
AstralStorm: nor KMS
MostAwesomeDude: zhasha: not my fault
AstralStorm: some real fail
AstralStorm: it looks like out of bounds
agd5f: AstralStorm: might have broken in idrs parser rework
agd5f: but that's generic mesa
AstralStorm: fe625f1 latest kernel commit I have
AstralStorm: agd5f: hmm, although I don't remember updating mesa recently, I might check that
AstralStorm: which should be the test point commit before it?
AstralStorm: (so as not to do a full bisection since 7.7)
agd5f: AstralStorm: I don't remember when it went in off hand
AstralStorm: I'm trying 7 day old mesa now as a bisection point
AstralStorm: since I think it worked then
cxo: blame the gits
AstralStorm: from 9fce12b894c3af33d7a0732332446893682a48d5 ;)
AstralStorm: if that fails, the bug is older
AstralStorm: and I'll try 14-day old
osiris: yay. tomb raider legend and portal are working - there're some rendering glitches but at least it starts now and renders good in general
cxo: how glitchy?
AstralStorm: likely water and fire
AstralStorm: ;)
cxo: does it look like doom1 on a 386?
AstralStorm: nah, far better
cxo: or unreal tournament 2003 on linux
AstralStorm: huh?
AstralStorm: ut2k3 was ok... on nvidia ;p
cxo: ....yeah
AstralStorm: haven't tried here yet
osiris: cxo: some Z problems, sometimes missing textures or objects
cxo: I think if the new 300 series cards from nvidia are any good, i'm going to switch back tonvidia, this ati business is just retarded if you like to play new games
osiris: cxo: I can play ut2004 without a problem on r300
AstralStorm: exactly
cxo: 5 year old game, 7 year old hardware
AstralStorm: yup
AstralStorm: try freespace 2 open instead ;p
AstralStorm: at 1920x1200 though, both can tax the hardware
cxo: heck Halo 1 "taxes" hardware, but it doesnt make it any good
agd5f: cxo: you can always use the proprietary driver in the meantime
AstralStorm: hmm
AstralStorm: agd5f: fails still
AstralStorm: I bet this is some problem with drm or ddx
AstralStorm: it works w/ older drm-next for instance
agd5f: AstralStorm: the parser rework was a while ago. month or two
AstralStorm: funky
AstralStorm: so it is not that
AstralStorm: I didn't have *that* old mesa
AstralStorm: maybe a week or two behind
AstralStorm: also, it *still* works with older revision of drm-next
AstralStorm: uh, older kernel
AstralStorm: I'll check what commit I had
AstralStorm: last commit there was d0c403e950d449c8c413a1fbf05dfec45ce03e55
cxo: agd5f, oh god, that doesnt work at all. xf86-video-ati has unpaperweighted my r700
AstralStorm: cxo: need an olden xorg and kernel for propietary to wrok
AstralStorm: wrok = wreak havok ;)
AstralStorm: or work with a tpyo
cxo: heh its like a conundrum almost
cxo: DAAMIT is what the enquirer often uses, i always thought that was cool
adamk: cxo, Why can't you use the proprietary driver with your r700?
cxo: X either segfaults or just locks-up the machine (depending on the distro)
adamk: Ahhh.
AstralStorm: this is the mark of too new kernel/X server for the driver
AstralStorm: oh btw
AstralStorm: is there a way to control brightness yet?
AstralStorm: if so, how to do that
cxo: xrandr maybe?
AstralStorm: brightness, not on/off
AstralStorm: no such property here
cxo: do you have sun glasses?
AstralStorm: ...
AstralStorm: har har
AstralStorm: I'm talking about power saving
mjg59: brightness on laptops?
osiris: airlied: I'd like to push some fixes, namely: 1) r300: remove unneeded includes, 2) radeon: add missing miptree reference, 3) r300: add missing texformat, 4) radeon/r300: remove unnecessary calls to radeon_firevertices, 5) radeon: remove unnecessary call to radeonEmitState and 6) radeon: workaround for #22742
osiris: airlied: could you review?
osiris: otaylor: can you check if "radeon/r300: remove unnecessary calls to radeon_firevertices" and "radeon: remove unnecessary call to radeonEmitState" fix the bo accounting problem for you?
agd5f: AstralStorm: use the apci brightness controls
glisse: osiris: where are the patches ?
osiris: glisse: in my private repo on fdo
AstralStorm: agd5f: how? which app
agd5f: osiris: they look good to me
agd5f: AstralStorm: via hotkeys or whatever you have mapped to execute those methods
AstralStorm: har har
AstralStorm: which I haven't
AstralStorm: how do I do that then
AstralStorm: I mean execute the acpi method from, say, commandline
AstralStorm: (then I can use lineak)
mattst88: osiris: what kind of performance increase does hw blitting provide?
mattst88: I hope that's not indicative of the performance increase :)
Ghworg: AstralStorm: "echo $NUM > /sys/class/backlight/acpi_video0/brightness", or something like that
osiris: mattst88: depends, I think it's up to 100x
mattst88: good lord :D
osiris: mattst88: depending on the size of the buffer you're blitting
mattst88: of course
agd5f: AstralStorm: /sys/class/backlight
kdekorte: osiris, r300 only or does it apply to r5xx and higher as well?
osiris: mattst88: looks like it's over 1000x actually
otaylor: osiris: are these patches committed to mesa?
otaylor: osiris: Oh, I see what you said about your repo on fdo
osiris: mattst88: results for current sw blit: glCopyTexImage(1024 x 1024): 1.5 copies/sec, 6.2 Mpixels/sec
osiris: mattst88: hw blit: glCopyTexImage(1024 x 1024): 2175.3 copies/sec, 8701.0 Mpixels/sec
otaylor: osiris: I'm a little reluctant to do stuff right now since I'm getting frequent system hard locks right now when I start gnome-shell :-(, but when I'm at a good point to have to reboot I'll give it a try
osiris: kdekorte: currently it's r500 only, but r300 will be there soon
kdekorte: otaylor, as a side note have you seen my clutter/gstreamer app fosfor?
otaylor: kdekorte: No, I haven't. Is it cool? :-)
kdekorte: osiris, I have an r600 that could use something like that
kdekorte: otaylor, I think it is:http://kdekorte.blogspot.com/search/label/fosfor
otaylor: kdekorte: neat
osiris: mattst88: we could probably increase the transfer rate almost up to theoretical hw limits if we had support for color buffer and texture tiling
kdekorte: otaylor, It does a lot of things, but needs work, but I think it could go pretty far
cxo: its meant to be a media player?
kdekorte: cxo yeah.. kinda like gnome-mplayer or totem
cxo: can it use libxine instead of gst?
kdekorte: cxo, no... but gst is pretty decent these days...
cxo: ...like ati drivers, right.
cxo: I once got so frustrated with gstreamer, that i spent 8 hours straight writing a gst to libxine wrapper, ld_preload library that would just hijack anything going to gst. worked pretty well, but the meta data retrieval process in gst is seriously convoluted, so i didnt get round to finishing it
airlied: osiris: they look fine to me from a quick review, I'd worry they might break DRI1, esp the Scissor flush removal
airlied: since DRI1 does scissor emit in the kernel from memory
cxo: Does DRI2 replace DRI1 or do they work in parallel?
airlied: replace
[Enrico]: mhm can i ask if there is some ETA for the radeon r600 KMS and 3d? just to know how long i should use the git stuff eheheh
osiris: airlied: hmm, I'm not sure how the scissors may brake if they take an effect only during rendering
airlied: osiris: /* We don't pipeline cliprect changes */
airlied: osiris: thats because the kernel does the cliprects in dri1 at the start of the command buf submission
airlied: they can't change mid command buffer so we need to flush
MostAwesomeDude: It's magical.
osiris: airlied: aah, ok then
osiris: airlied: I'll disable it for DRI2 only
airlied: osiris: yeah that works for me
airlied: osiris: I assume it still passes as much of piglit as it did before these chanegs?
osiris: airlied: I'm checking right now
AstralStorm: [Enrico]: it works here
AstralStorm: [Enrico]: on my r6xx w/ KMS
[Enrico]: AstralStorm: also here
AstralStorm: slower than w/o KMS
[Enrico]: but i was just curious
AstralStorm: uhm
AstralStorm: the drm will be in 2.6.32
[Enrico]: AstralStorm: and i say more, here is works really great, both 3d and kms
[Enrico]: yes i know that
AstralStorm: KMS is slow in 2D
[Enrico]: but mesa libdrm and video-ati? :D
AstralStorm: this should be fixed :)
kdekorte: [Enrico], Fedora 12 pretty much works out of the box with r600, just need to install the mesa-dri-drivers-experimental package
[Enrico]: AstralStorm: here it is not slow at all :D
[Enrico]: kdekorte: i use gentoo eheheh
AstralStorm: mesa 7.7, driver already has support
AstralStorm: [Enrico]: slow as in 2x-3x slower than w/o KMS
AstralStorm: I get visible screen refreshes w/ KMS
[Enrico]: AstralStorm: i don't
[Enrico]: here seems the same speed
AstralStorm: try refreshing a terminal
AstralStorm: or smooth scrolling in firefox
AstralStorm: or flash
[Enrico]: AstralStorm: already done :D
AstralStorm: easily visible degradation
AstralStorm: w/o composite?
[Enrico]: AstralStorm: really i see no difference
kdekorte: KMS is a little slower than DRI1, but not really noticeable for most things
[Enrico]: AstralStorm: no i tried ony with composite
AstralStorm: kdekorte: 2D w/o composite is *slow*
AstralStorm: for some reason
AstralStorm: it shouldn't be
AstralStorm: starts xcompmgr
AstralStorm: didn't speed stuff up
AstralStorm: maybe it's urxvt toggling something slow
kdekorte: AstralStorm, gnome, kde, other?
cxo: heh xcompmgr
[Enrico]: no difference here, i just tried disabling composite
[Enrico]: i use kde
AstralStorm: hmmh
AstralStorm: which card?
AstralStorm: here it's HD 3850
kdekorte: r600 here on gnome
cxo: I remember using transet and xcompmgr back in the day to get the effects going before all this beryl/compiz/aiglx/whatever came round
[Enrico]: hd 3470
AstralStorm: hmm
kdekorte: 3650 here
cxo: 4870?
AstralStorm: now, why mine is slow in 2D and your is not?
[Enrico]: AstralStorm: i'm using zen-sources .31 zen7 + drm-next
AstralStorm: slow as in visibly slow
AstralStorm: [Enrico]: I'm using 2.6.32-rc6-zen1 latest
cxo: what 2d test are you using?
AstralStorm: which has drm-next as well
AstralStorm: no test, just eyeballing
AstralStorm: it's very visible
AstralStorm: vs non-KMS
kdekorte: using gtkperf -c 500 -a (which is cpu bound) in DRI1 I get the complete test in 40-50 seconds.. in DRI2 it is 80-90
cxo: time { find / ; } <---- 2D Benchmark
AstralStorm: switching tags w/ awesome to firefox = some 1,5s
AstralStorm: on DRI2
AstralStorm: on DRI1, split second
[Enrico]: AstralStorm: don't know..... all my git stuff if from today
AstralStorm: oh, wait
AstralStorm: it was due to composite
AstralStorm: killed xcompmgr, it's faster again
AstralStorm: but still slower
AstralStorm: esp. in urxvt
AstralStorm: I see... scanline-like behavior
kdekorte: I use composite in metacity, doesn't really change it
AstralStorm: kdekorte: you don't count, you have r7xx
AstralStorm: ;p
kdekorte: I have r6xx
AstralStorm: 4870 is not.
kdekorte: I have a 3650
AstralStorm: oh
AstralStorm: well, then why do I get this slowdown
AstralStorm: any of you could try a fullscreen ncurses app in urxvt?
AstralStorm: (xterm is slow as well I think)
Hald: Hi all. What can I do to get better performance in my ATI 9600 on ubuntu 9.10?
kdekorte: xterm running 1650x1050 doing an ls is near instant
[Enrico]: AstralStorm: here scrolling in vim is superfast in yakuake (aka konsole based drop down terminal in kde)
kdekorte: AstralStorm, kernel and libdrm can really affect things
AstralStorm: the slowness manifests mostly switching tags
AstralStorm: a'la virtual desktops
AstralStorm: which is a full redraw
kdekorte: dual screen virt desktop switch here is pretty quick here
AstralStorm: ?
otaylor: osiris: seems to work well (fixes the problem, no immediately apparent regressions)
AstralStorm: doesn't count
AstralStorm: or maybe it does
AstralStorm: if a screen gets redrawn, the slowness shows
AstralStorm: it is slow enough to be annoying at times
taiu: AstralStorm: your card's AGP by any chance?
AstralStorm: no
AstralStorm: pci express
joyful_dep: hi there
taiu: AstralStorm: let's see xorg.log from kms then
AstralStorm: http://dpaste.com/118804/
AstralStorm: that's lspci
AstralStorm: log: http://dpaste.com/118805/
airlied: agd5f: that bug isn't evdev related, its hung in the DRILock, its the evdev handler that notices and pritns the backtrace
joyful_dep: could anyone be of help?
AstralStorm: joyful_dep: ask the real question and you might be answered
AstralStorm: :)
joyful_dep: i'm a newbie here thnx
kdekorte: AstralStorm, what version of libdrm do you have?
AstralStorm: kdekorte: some git
osiris: otaylor: great :)
AstralStorm: quite fresh
Luzipher: joyful_dep: just ask, that'll be the easiest way to get an answer ;)
AstralStorm: Installed time Sat Oct 10 00:08:57 2009
AstralStorm: hm, month old != fresh ;p
AstralStorm: but it's not ancient at least
AstralStorm: ddx is latest
AstralStorm: (from today)
kdekorte: AstralStorm, what does 'pkg-config --modversion libdrm' say
kdekorte: probably want 2.4.15 and rebuild ddx against that
joyful_dep: well i was hoping to get my external monitor (which btw is an lg w2361v) work in the resolution of 1920X1080 which it supports).my gpu is ati mobility radeon x2100 and my os is ubuntu 9.10
Luzipher: joyful_dep: so it doesn't have that desired resolution or doesn't it work at all ? it's a laptop i guess ?
Ghworg: Hmmm, mesa really doesn't like building in parallel. Weird errors occur, but it build fine with -j1
kdekorte: joyful_dep, plugin in the external display and put the output of xrandr at dpaste.com
joyful_dep: its a laptop , in the preferences->display the desired resolution doesnt even appear
Luzipher: joyful_dep: do as kdekorte said. xrandr is a command you have to type into a console/xterm/...
joyful_dep: http://dpaste.com/118808/
AstralStorm: kdekorte: 2.4.15
kdekorte: joyful_dep, try this command 'xrandr --output DVI-0 --auto --right-of VGA-0
joyful_dep: works perfectly
joyful_dep: is this configuration permanent?
kdekorte: there is a tool called 'gnome-display-properties' that should help
kdekorte: the xrandr command only works pre reboot, the gnome-display-properties should be more perminant
AstralStorm: and also, you can set that in hal device config
AstralStorm: or in xorg.conf
AstralStorm: but gnome-display-properties should produce the right hal file with settings
joyful_dep: gnome-display properties doesnt show me both screens
kdekorte: it should, or it does here...
kdekorte: is mirror screens set?
kdekorte: if so uncheck it
joyful_dep: mirror screens is unchecked
joyful_dep: shall i post a screenshot?
kdekorte: sure
joyful_dep: http://img4.imageshack.us/img4/2589/screenshotpk.png
kdekorte: joyful_dep, how about 'xrandr --output VGA-0 --auto'
kdekorte: does that make it appear
joyful_dep: nope
kdekorte: weird
kdekorte: gnome-display-properties should show you want xrandr does
joyful_dep: thank you guys you were really helpful
AstralStorm: kdekorte: so, anything wrong with my setup?
kdekorte: AstralStorm, nothing obvious
AstralStorm: well then, why is it slow
AstralStorm: always been like this
kdekorte: what does gtkperf -c 500 -a give as a result?
AstralStorm: wait
kdekorte: also, are you using an xorg.conf file? and if so do you have any weird options in it
AstralStorm: where do I get it?
AstralStorm: no, I don't.
AstralStorm: btw, I'm running 64-bit if that's important
kdekorte: for me gtkperf is a package in fedora
kdekorte: so am I
AstralStorm: ok, found it
AstralStorm: no package in this crummy distro I'm on now
AstralStorm: have to switch
kdekorte: Fedora 12 is pretty darn nice
osiris: airlied: looks like "radeon/r300: remove unnecessary calls to radeon_firevertices" isn't correct
MostAwesomeDude: osiris: Is there anything funky about your texrect r300g patch, beside the fact that it's massive hax?
osiris: MostAwesomeDude: it isn't a massive hax
osiris: MostAwesomeDude: that's the way to do the texrect, it's just the border calculations that are wrong
MostAwesomeDude: Well, *why* are they wrong? Is it an r300g problem, or a mesa st problem?
osiris: airlied: we certainly doesn't have to flush everytime in radeon_tex(sub)image - only when the texture is already referenced in unflushed cs
osiris: MostAwesomeDude: I think it's the pipe problem, because it doesn't provide us with the info about the tex border
osiris: MostAwesomeDude: there's only border color, but no info whether the texture has the border actually
osiris: airlied: any ideas how to easily track not flushed textures?
MostAwesomeDude: osiris: The border's not part of the texture size, is it?
osiris: MostAwesomeDude: I don't know
agd5f: MostAwesomeDude: I don't think you have to worry about the border
agd5f: jus the raw image
airlied: osiris: I thought mesa did some of that, but if not we can just check if the bo has any references
MostAwesomeDude: Hm. I'm gonna go search the standard. But I have a feeling that we can just check the texture size, straight-up.
osiris: airlied: also we could just allocate another bo
airlied: osiris: I'll have to get back into mesa to figure out the correct answer
airlied: osiris: texsubimage you can't
airlied: since I assume you want to operate on the contentes
osiris: airlied: right
osiris: airlied: but for teximage we could do it, just don't know how would it work with miptree
airlied: yeah lets not special case it
airlied: we should just check if the bo has any refs then flush it
osiris: airlied: cref > 0?
airlied: I think > 1
airlied: but I could be wrong, bbl &
osiris: airlied: seems to work with cref > 0
osiris: with cref > 1 too
osiris: airlied: do we really can just check the cref? aren't there any places where the bo is shared?
osiris: how has the anholt.* files for openarena benchmarking?
osiris: *who
osiris: adamk: ^^^
adamk: osiris, http://adam.npark.com/anholt.dm_68 http://adam.npark.com/anholt.cfg
osiris: adamk: thx
AstralStorm: kdekorte: http://wklej.org/id/201477/ - gtkperf results on KMS
AstralStorm: as you can see, they're horrible
AstralStorm: esp. scroll and those gtk drawing area ops
DeX77: agd5f: I still think I got a race condition somewhre that prevents firmware loading (sometimes)
agd5f: MostAwesomeDude: we ought to implement GL_ARB_draw_buffers in r300g/r600g. doesn't look like it would be too hard
MostAwesomeDude: agd5f: Lemme refresh my memory.
agd5f: MostAwesomeDude: multiple render targets
MostAwesomeDude: Oh, MRTs.
MostAwesomeDude: It's already in r300g, but I don't know if mesa st does it.
MostAwesomeDude: Well, now that I think about it...
agd5f: sw mesa claims to support it
MostAwesomeDude: The core state setup has MRT, but I don't think the frag shader can handle it.
adamk_: AstralStorm: For comparison purposes, here's what I get: http://pastebin.com/m24971f43
agd5f: MostAwesomeDude: sure it can. you select the target in the output instruction
osiris: airlied: unfortunately not all bo space not accounted problems are fixed. to really fix it radeon_firevertices should flush the cmdbuf only up to the last draw packet
adamk_: KMS on an x850. Seems to be considerably better than what you are getting.
MostAwesomeDude: agd5f: Sorry, I should have been less terse. I don't think r300compiler outputs MRT selection.
agd5f: MostAwesomeDude: yeah, probably not, but it shouldn't be hard to add
MostAwesomeDude: Lemme see if there's a glean/piglit test for it.
MostAwesomeDude: progs/tests/drawbuffers in Mesa, but not in piglit. Alright.
DanaG: is pondering taking a class with this course description: "Illumination models, reflectance, absorption, emittance, Gouraud shading, Phong shading, raytracing polyhedra and other modeling primitives, coherence, acceleration methods, radiosity, form factors, advanced algorithms. 3 lectures, 1 laboratory."
MostAwesomeDude: DanaG: Ooh, looks like basics of rasterized lighting. Might be interesting.
DanaG: I'm just not sure how much work it'd be, added on top of my other stuff that quarter.
airlied: osiris: thats not going to work, you can't half flush a cmdbuf
MostAwesomeDude: Well, I learned all that stuff from Internets, but a class might be fun.
osiris: airlied: why? just pass the size smaller than it actually is
airlied: osiris: you should also check kernel busy as well I suspect
airlied: but we'll hit that anyways
airlied: when we use the texture
yangman: DanaG: depends on how it's taught, and how much actual coding is expected
airlied: so cref just means we have a reference to it in out unsubmitted command stream
airlied: I think we always havea cref so we need to check > 1
osiris: airlied: we need some general interface for checking if the bo is referenced in unflushed command stream
osiris: airlied: it is also needed for glBufferSubDataARB
osiris: airlied: and could be used for the oq instead of current implementation
MostAwesomeDude: osiris: If you're feeling charitable, you could add a flag to libdrm's radeon_bo struct for it.
MostAwesomeDude: In add_buffer, mark it; when the buffers are cleared, reset it.
osiris: MostAwesomeDude: good idea, I'll add it if airlied and glisse will agree
MostAwesomeDude: The *really* nice thing would be to also add is_buffer_referenced to libdrm_radeon, but I won't hold my breath, especially since I found out I don't need it.
airlied: osiris: yeah seems like a sane plane to just add is_buffer_reference
kdekorte: AstralStorm, might try pulling drm-next into your kernel. Might help with the speed of it.
DanaG: wishes for KMS with power savings. =รพ
osiris: airlied: can bo be referenced between two contexts?
osiris: *shared
kdekorte: agd5f, any word on the approval of r6xx interrupts yet?
agd5f: kdekorte: not yet
airlied: osiris: in theory, but then flushing it is left to the app
airlied: since there is no way to know if they have unqueued commands in another context
osiris: airlied: then we can't hold the is_buffer_referenced field in the bo, it has to be per cs manager
airlied: well you might get an extra flush
kdekorte: How far along is the r600g code? Just starting or some percentage of the existing code?
airlied: kdekorte: -5%?
kdekorte: airlied, ha... that is pretty low
airlied: MostAwesomeDude: you should take the keithw approach for r600
airlied: start from the DRI driver and delete code, much easier than wriring code
kdekorte: airlied, if I didn't say thanks for fixing r6xx hangs.. thanks! BTW, it seems that pcie_aspm=off, was not the real solution, so what was?
agd5f: kdekorte: possibly this: http://git.kernel.org/?p=linux/kernel/git/airlied/drm-2.6.git;a=commit;h=d6f28938d9426d12eea1578949f1d73d24ad37ec
airlied: kdekorte: Zajec found the cause, when we set the ring buffer up we wrote a register read it back and wrote it again
osiris: airlied: ... or no flush at all - and that would be a problem
airlied: osiris: how whould you get no flush?
airlied: as I said it isn't this contexts job to flush other contexts
airlied: GL leaves that to apps
MostAwesomeDude: airlied: That's what I'm doing. You can't see it because I didn't commit the files from them, but I'm kind of blending r300g, r600, and identity together.
Zajec: does someone experience locksup with 3D and Xv?
osiris: airlied: both contexts have the bo in the queue, one context flushes. second one is calling setteximage which checks if the bo is referenced and it won't be because the field has been cleared by the other context
kdekorte: airlied, wow... amazing that a couple little lines could cause so much havoc
Zajec: i was using KDE4 with effects enabled and when switching to full screen got lock uo
osiris: airlied: unless we change the is_referenced field from bool to a counter
airlied: osiris: cref is a counter
airlied: I was just going to wrap something to check cref > 1
eosie: MostAwesomeDude, osiris: FYI, gallium does not support texture borders
osiris: airlied: no, that won't work
airlied: osiris: why not?
osiris: airlied: because the bo can be referenced in few places (not necesserly in CS)
airlied: osiris: it only matter if its in the CS
airlied: I'm not sure where else can hold refs
airlied: we've either emitted a reloc for it already and its used
airlied: or we haven't and we don't care
osiris: airlied: hmm, what about bos for VBOs or FBOs?
MostAwesomeDude: eosie: That's what I'm finding too, yes.
airlied: osiris: FBOs should be the same if we've emitted a reloc
airlied: we only care if we've emitted drawing that uses things
airlied: so we shouldn't just have references in the command stream
airlied: if there are no references in the command stream we just need to bo wait if are sw fallback
osiris: airlied: I've already found a case where one bo is referenced by two objects, in that case cref > 1 want be correct for us
airlied: osiris: well thats inefficent, so maybe we can make it smarter
osiris: airlied: store is_referenced counter in the bo, and inc it during reloc, decrease during cs emit
MostAwesomeDude: Well, not quite during emit. Don't you want to wait until the buffers are cleared by the driver?
osiris: MostAwesomeDude: nope, bo_map will do it
MostAwesomeDude: osiris: Well, what if it's a VBO that you're going to render a bunch with, and you're not going to map?
MostAwesomeDude: You might not want to unref your BOs. You might want to keep them ref'd for a while.
osiris: MostAwesomeDude: you don't understand. we only need the information whether the bo is in an unflushed cs, if it's then flush the cs because user is going to change the data in it (either through TexImage, TexSubImage or glBufferSubData)
osiris: and before the data will be changed, the bo_map will be called
airlied: osiris: have you asked the most important question yet? what does Intel do? ;-)
biotube: break things?
osiris: hehe
airlied: normally every problem we hit with our mesa driver, they've hit 6 mths ago and solved
osiris: airlied: can't we do it ourway for once? ;)
airlied: osiris: we have a bad habit of doing it wrong
airlied: usually because we don't have a QA team
airlied: doing regression testing on our drivers
DeX77: re
osiris: airlied: they check the relocation tree
osiris: tormod: can you do something with #478648 ?
osiris: tormod: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/478648
osiris: airlied: so what do you suggest?
airlied: osiris: can we add an interface that handles it now? even inefficently?
airlied: and then fix it under the hood afterwards?
osiris: airlied: sure. what would be current solution? intel's?
airlied: osiris: either cref or Intels.
osiris: votes for intels
osiris: airlied: cref will give incorrect results for some cases
airlied: it'll flush too often, I don't see the not flush at all case
kdekorte: osiris, that was fixed in git a long time ago. I remember opening that case
osiris: airlied: no flush at all will happen, if bo held by texture object (first ref) will be also held by renderbuffer (second ref), then in cs will be third ref
osiris: kdekorte: yes, but the fix isn't yet in the ubuntu kernel
airlied: osiris: if the check is cref > 1 it should be fine
airlied: osiris: you'll flush when not necessary since it has 2 refs
osiris: airlied: aah, right. sorry, I got confused
quieteyes: a very simple question: based on what I've read between the DRI and radeon wikis, the X1xxx line of cards is the highest line that supports accelerated 3d, correct? or is the documentation outdated already (I know that there is work on the HD series going on)
biotube: the support for HD 3xxx and 4xxx is quite good, just unreleased
chithead: with latest mesa from git, everything up to 4890 supports 3d
quieteyes: cool, thanks. So the docs are a bit outdated (and will be completely outdated in the near future it sounds like)
chithead: where did you read this? http://wiki.x.org/wiki/RadeonFeature lists r6xx 3d as "mostly"
quieteyes: that's one of them
MostAwesomeDude: MOSTLY means that it's not perfect.
quieteyes: also http://dri.freedesktop.org/wiki/ATIRadeon?highlight=(CategoryHardware)#head-3fad277d16434060da82a2fb886d11ad523897fe
Luzipher: quieteyes: it works, but slow and with artifacts in some apps
quieteyes: d'oh! just noticed someone updated it recently (I've been watching it for months). That's what I get for not going there before asking...sorry
Luzipher: quieteyes: so "MOSTLY" is really that: mostly ;)
chithead: supertuxkart and world of padman work well on my rs780
Luzipher: quieteyes: you can check http://wiki.x.org/wiki/RadeonProgram for a more detailed picture
quieteyes: thanks!
kdekorte: Neverwinter Nights seems to have gotten worse with the mesa SVN code... used to display quite good
osiris: kdekorte: there's a regression in NV program handling
osiris: kdekorte: does the game output any errors?
kdekorte: Let me try it again... I'm trying second life now... it still seems ok
osiris: kdekorte: also there're other regressions since texformat-rework branch got merged
kdekorte: yeah textures are quite bad, as is the cursor
MostAwesomeDude: I need to get less bored. http://github.com/MostAwesomeDude/madsnippets/blob/master/glxinfo.py
kdekorte: osiris, no errors from nwn as far as I can tell
MostAwesomeDude: http://paste.pocoo.org/show/149888/
osiris: kdekorte: can you bisect it?
chithead: yes, I also noticed some regressions. spring used to work ok with some glitches, then it refused to start with some fragment program error, and now it segfaults in r600_dri.so
osiris: chithead: bisect, please
chithead: the transition from fragment program error to segfault was between 5th november and today, I can investigate further
osiris: no hurry
chithead: http://dpaste.com/118919/ has the backtrace of the crash, in case it is interesting
chithead: http://dpaste.com/118924/ fragment program error I got before
osiris: you should probably report these
chithead: I noticed that there were four arb prog parser related commits, I suspect one of them triggered this
chithead: osiris: first commit that segfaults is 4e4c2ee1fd574d1d651c559f46afb6ca5487156d
chithead: I will report a bug
eosie: why does mesa expose ARB_shading_language_120? ARB has never standardized such an extension
osiris: airlied: are you going to implement the bo_is_referenced interface, or should I do it?
airlied: osiris: I'm not doing mesa for a while
airlied: so feel free
airlied: for some reason ppl seem to care more about their machines booting than 3D working ;-)
Zajec: airlied: :D
Zajec: airlied: did you think about drm-radeon branch? for more experiments in that?
airlied: Zajec: yeah when I get time I'll rearragne things
DanaG: http://www.mail-archive.com/dri-devel@lists.sourceforge.net/msg43334.html
DanaG: looks forward to seeing that sort of thing.
DanaG: Dynamic-ness doesn't matter to me as much as as just static power management.
DanaG: oops, 'as as'.
DanaG: hmm, is this thing read-only, or read-write?
AstralStorm: adamk_: it does contain drm-next
AstralStorm: I mean, my kernel
AstralStorm: adamk_: commit fe625f1
AstralStorm: although it is 2 commits back on drm-linus
AstralStorm: so, any idea why it is slow?
AstralStorm: and non-KMS is not
AstralStorm: i've pasted xorg.0.log earlier
AstralStorm: kdekorte: oh, that was you. my kernel contains drm-next up to commit fe625f1
AstralStorm: there are 2 extra commits in drm-linus, but they won't affect the speed
AstralStorm: it might be caused by... cpufreq
AstralStorm: with cpufreq set to performance: Total time: 123,74
AstralStorm: so it is cpu-bound on something
AstralStorm: this means KMS has a nasty bug somewhere
AstralStorm: also, it is cpu-bound
AstralStorm: any idea why?
biotube: only thing I can think of is that the mode switch is involved
AstralStorm: now, why would it be slower... someone needs to do a visual diff on kms and non-kms
AstralStorm: it's been slow like that since KMS has been added
agd5f: AstralStorm: profile it
AstralStorm: how do I go about profiling that? :) not sure if sysprof works properly now
AstralStorm: or oprofile
AstralStorm: do they?
AstralStorm: I'm now testing the glx bug, the commit I tried doesn't work with latest drm-next
AstralStorm: trying a newer one, the one with Mesa Project and SGI change ;>
AstralStorm: there's one reason I might be running slow
AstralStorm: that reason would be my -g3 in the ddx and mesa
AstralStorm: but it's very unlikely
biotube: not really
AstralStorm: (tracing and debug are disabled)
biotube: some things helpful to debugging information are removed as optimizations
DanaG: I know of gcc -g, but does g take a number?
AstralStorm: it does, read the manpage
AstralStorm: default is level 2
AstralStorm: level 3 adds macro support
AstralStorm: which is very useful :P
DanaG: cool, I'll have to try that some time.
AstralStorm: I've updated pixman, ddx and rebuilt mesa to that commit
AstralStorm: oh, and libdrm as well
AstralStorm: just in case
AstralStorm: the fragment program compile fails again
AstralStorm: hmm, intriguing
AstralStorm: it might be... linked to drm-next version
AstralStorm: and not to mesa version
AstralStorm: I'll test that hypothesis in a second
agd5f: AstralStorm: might be bug 25024
eosie: MostAwesomeDude: do you happen to know what osiris's hack with get_tex_no_border was supposed to fix?
eosie: get_tex_size_no_border, even
AstralStorm: agd5f: might be
AstralStorm: someone broke shader programs?
AstralStorm: but I'll check my merge history to see what the previous version of mesa was
AstralStorm: wow
AstralStorm: previous mesa was month old
AstralStorm: * x11-dri/mesa-scm::x11 Sat Oct 10 00:08:59 UTC 2009
AstralStorm: I'll check that commit
AstralStorm: agd5f: could you be so nice and tell me the commit id right before that?
AstralStorm: (a working one)
cxo: If you guys took the r700 driver, put the r800 pci ids in it, and let it go, what would happen? Has anyone tried it?
AstralStorm: don't worry
AstralStorm: found it
biotube: cxo: there are enough differences just in a single family
AstralStorm: cxo: it'll likely break, but worth a shot
biotube: probably work for 2d, but 3d it's unlikely
cxo: The basic init and 2d stuff is likely the same
cxo: yeah
biotube: I don't think the 2d stuff's changed in the last decade
AstralStorm: no, it did
airlied: there i no 2D stuff
airlied: in any new chips
AstralStorm: exactly
AstralStorm: so it's all done with the shader pipeline
biotube: really?
airlied: basic init and maybe analog vga might work
cxo: yeah
cxo: 2d is done through 3d
airlied: as they change least
AstralStorm: airlied: wasn't there some fix later up that commit that was supposed to fix the futz?
cxo: Does anyone here have an r800?
MostAwesomeDude: r800 3D should work using r700 code, in theory. I'm sure there's a bunch of things that will make it break though.
AstralStorm: agd5f: do you recommend this commit for a test? 577a598d mesa: Export S3_s3tc as well.
cxo: small register changes could break a lot, even if its a small fix
airlied: considering the diffs from r600->r700 for 3D engine I'd expect a similiar diff
airlied: which is definitely non-trivial
AstralStorm: actually, this one should work
AstralStorm: 96e938f
MostAwesomeDude: airlied: But not as much as r400->r500 hopefully.
AstralStorm: the one it has been merged to
cxo: but r700 was >> than r600
cxo: r800 isnt >> r700
cxo: (or at least the marketing doesn't make it seem otherwise)
airlied: cxo: doesn't mean anything
AstralStorm: even a trivial change is enough to break it
airlied: a slow r500 is worse than a fast r400
AstralStorm: the joys of low-level programming ;)
airlied: it doesn't mean they aren't that different
cxo: performance either in that respect. The 4870 still holds its own, while the 4850 kicked the 3870
cxo: slow r700 > fast r600
AstralStorm: that ">" depends on a lot of things
AstralStorm: one being proper driver support ;p
cxo: heh
AstralStorm: agd5f: now building 96e938f62c729fab74601627d54c9c4cf499ebdf - if it works w/ mplayer, it is that mesa_7_6_branch merge
AstralStorm: someone gets to fix the parser then
AstralStorm: and bash the person who futzed the merge ;p
agd5f: cxo: won't just work, the display hardware is all new
agd5f: 3d engine is also different. bigger changes than r6xx to r7xx
MostAwesomeDude: :C
AstralStorm: and what about docs? available yet? ;p
cxo: Definitely been down played then
agd5f: AstralStorm: not yet
AstralStorm: cxo: why would they advertise stuff confusing to a typical client?
cxo: all these big changes are just there for the fun of it?
AstralStorm: the only real important thing is that it's more geared for GPU computations
AstralStorm: you know, CUDA-like
agd5f: cxo: they are there to support eyefinity and DX11
hoo-hah: hello kind folk. Would disabling staging drivers (radeon) KMS adversely affect 3d performance?
AstralStorm: hmm :)
AstralStorm: hoo-hah: not, why would it
MostAwesomeDude: agd5f: IIUC the only changes from r600->r700 were in the ISA?
cxo: From the benchmarks I've seen on Toms, 5870 > 4870 >>> 3870
AstralStorm: it only toggles the radeon.modesetting default
MostAwesomeDude: And they weren't that invasive...
hoo-hah: I still would like to use the dev ati driver, but 3d performance isn't a necessity -- I only want good xv - out performance
biotube: hoo-hah: kms is still slower than regular modesetting
agd5f: MostAwesomeDude: mostly
hoo-hah: AstralStorm: I dunno, wouldn't disabling it revert back to using DRI and not DRI2?
AstralStorm: uh, radeon.modeset default
AstralStorm: hoo-hah: no
hoo-hah: biotube: does this affect X too
AstralStorm: you can do that with radeon.modeset=0 option as well
AstralStorm: here, 2D is slower than w/o KMS for some reason
AstralStorm: but that doesn't include Xv
AstralStorm: I'm going to profile that
hoo-hah: I can't remember why, but it was a combination of disabling KMS and some other option, resulting in mplayer unable to playback video
cxo: agd5f, is there anything on the table though, about releasing docs without a strategic 2 year delay
hoo-hah: xv-out
hoo-hah: so I was thinking there was some connection b/w the two
agd5f: cxo: yeah. we plan to release docs
AstralStorm: agd5f: no, commit 96e938f62c729fab74601627d54c9c4cf499ebdf fails as well
AstralStorm: I bet it's KMS and/or DRM related
agd5f: AstralStorm: it would probably be easier to bisect mesa
AstralStorm: agd5f: I am bisecting mesa though ;p
agd5f: AstralStorm: sounds like you are doing it manually though
AstralStorm: I'll have to test DRI1 and if that happens to work, bisect DRM :/
AstralStorm: agd5f: semi-manually
AstralStorm: I was asking you for a good good commit to start
AstralStorm: to not bisect the whole mesa
AstralStorm: it's not that one ;p
AstralStorm: so, I get to try my oct 10 one
AstralStorm: and bisect from that
AstralStorm: so at least we have some good/bad bounds
AstralStorm: between oct 10 and 96e938f62c729fab74601627d54c9c4cf499ebdf
cxo: Isnt there a group called AstralStorm
cxo: or was it Astral Projection
MostAwesomeDude: Astral Projection is a trance group.
AstralStorm: yeah, Astral Projection is a trance group
AstralStorm: but my nick is unrelated to that kind of astral ;p
AstralStorm: it's related to space weather instead
AstralStorm: http://en.wikipedia.org/wiki/Coronal_mass_ejection
AstralStorm: but this page is better http://en.wikipedia.org/wiki/Geomagnetic_storm
AstralStorm: agd5f: I have 8 steps to test
AstralStorm: that'll take a while
Pallokala: are there some known problems or changes with KMS and DPMS?
AstralStorm: some changes, yes, extra debugfs info I think
AstralStorm: but just read the git log
Pallokala: ok, then this might be caused by something else
AstralStorm: it depends on what your previous version of KMS was
AstralStorm: and whether your card is r7xx or r6xx or r3xx
Pallokala: r6xx and the state before going to KMS
AstralStorm: ?
Pallokala: but I believe my problem is more caused by xserver 1.7
AstralStorm: "state before going to KMS" being?
Pallokala: EXA without KMS
AstralStorm: dpms works fine here btw on r6xx (as opposed to speed)
AstralStorm: ah
AstralStorm: but which kernel?
Pallokala: 2.6.32_rc6
Pallokala: and my problem is related to screensavers not enabling dpms anymore and I have to enable it with xset
AstralStorm: oh that
AstralStorm: X server fail then.
AstralStorm: or some missing flag in the ddx
AstralStorm: either way, write a fd.o bug
Pallokala: ok, thanks
AstralStorm: agd5f: do I get to restart X server when testing new mesa? I think I might have to do that :/
AstralStorm: (due to rxxx_dri.so)
AstralStorm: yes, it seems so
cxo: what was that game that uses the quake3 engine and begins with Nex...us
cxo: Nexuiz !
Pallokala: nexuiz?
cxo: got it
cxo: that works alright with r700 doesnt it?
eosie: AstralStorm: no
AstralStorm: hmmh
AstralStorm: eosie: so it's not mesa-related I bet
AstralStorm: instead, drm-related
AstralStorm: what a pain in my butt. I'll get to bisect drm
cxo: Do any of you guys have demo001 from the original Quake 3?
AstralStorm: of course we don't ;)
AstralStorm: it's copywronged
cxo: No its not. Its just a recording. Its on planet quake, but you got to go through their bs registration thing, its free, but i dont want to
AstralStorm: use google power? ;p
cxo: I dont know what the file extension was
cxo: s/know/remember
AstralStorm: so run the demo in demo version and see
AstralStorm: :)
cxo: c'mon someone has to have an iso of that on their hard drive
cxo: timedemo001 was legendary!
MostAwesomeDude: cxo: bugmenot.com
cxo: i think i found it
cxo: But i think these days those tests would be severely cpu bound
cxo: beats glxgears at least :)
AstralStorm: not in high res
AstralStorm: try at 1920x1200 and see ;)
cxo: well my monitor only goes up to 1280x1024
AstralStorm: hmmh
AstralStorm: get a better screen? ;p also, the card can scale down I think
AstralStorm: it won't look any better, but will stress the gpu
AstralStorm: kind of a poor man's antialiasing
AstralStorm: (more properly called oversampling)
AstralStorm: the scaling is done by hardware, but in a poor way - only bilinear I think
AstralStorm: modern FSAA have advanced FIR filters instead
cxo: I'd be keen on to see if it will beat my Geforce 256 (pre geforce 1), which gets 100fps at 1024x768
AstralStorm: here my r6xx got some 60 FPS at 1920x1200 max detail
AstralStorm: which is not stellar at all
cxo: on demo001?
AstralStorm: no, on something of mine
AstralStorm: with quake 3 demo version
AstralStorm: ioquake3 to be exact
AstralStorm: note that in windows, neverwinter nights 2 (which is a badly misoptimized engine) runs at some 30 FPS 1440x960 or such
AstralStorm: with a lot of detail (but not really max)
AstralStorm: (very close though)
AstralStorm: freespace 2 open taxes the card in highest detail in some real hot demos
AstralStorm: (esp. when there are many asteroids around, those use shaders - in windows)
AstralStorm: (and there's extra heat)
AstralStorm: so yes, hd 3850 is too weak to run 1920x1200 ;p
cxo: i'm downloading the q3demo, i think there is a timedemo in it
AstralStorm: (and yes, guys from freespace 2 open and the artwork project have done a great job)
AstralStorm: cxo: no, there's not
cxo: suckage
cxo: do you know what the file extension is for those files?
AstralStorm: I think .q3d
AstralStorm: but know, not really
AstralStorm: be back in a bit, getting a test w/o KMS
cxo: the extension is dm3
cxo: i got the file from the q3demo.tar.gz.sh file
cxo: but its not compatible with openarena
AstralStorm: I've upped the kernel to one with drm-linus
AstralStorm: heh, my old kernel exploded w/ KMS+gl - hard reboot ;p
AstralStorm: the new one exploded (not the one I'm running now) exploded w/o KMS. nice OOPS
AstralStorm: meh
AstralStorm: I can't find the working revision w/ KMS right now
AstralStorm: I bet 2.6.32-rc4 one was working, so...
AstralStorm: it is 100% DRM/DDX bug
AstralStorm: not mesa
AstralStorm: unless I picked the "good" commit wrong
AstralStorm: hmmh
AstralStorm: and non-KMS works fine here with drm-linus
AstralStorm: but not -vo gl either :/
AstralStorm: with an older kernel, I got a warning from the gfx pipeline, maybe the new one is missing some debug
AstralStorm: so it seems mesa is sending bad data to the driver
AstralStorm: but older mesa fails too, at least the revision I thought was the "good" one
AstralStorm: hmm
AstralStorm: I'll run a bisection over all 7.7-devel
AstralStorm: any dev alive? I'm having a strange failure with older mesa here
AstralStorm: http://dpaste.com/119002/
AstralStorm: not sure it is the same fail or not
AstralStorm: that one was with cbf46ed670ef5a5c8a641730234dd7ae964c3170
DanaG: hmm, is it possible to stick my video card in low-power mode on radeon KMS?
AstralStorm: http://git.kernel.org/?p=linux/kernel/git/airlied/drm-2.6.git;a=commitdiff;h=0a5c1e61dbaceb6ce56281a3128a6912b0dcd043;hp=3e5cb98dfe87cc61d0a1119dd8aa2b1e4cfab424 - looks like fail
AstralStorm: note the second line
AstralStorm: it doesn't use i at all
AstralStorm: ah, right, I see now
AstralStorm: it's a modular junk
AstralStorm: why not use real modulo as opposed to broken >= check
cxo: Are you still on your bisect search?
cxo: you've been at it all day
cxo: i almost feel sorry for you now
AstralStorm: all day?
AstralStorm: I'm doing it in parallel with other stuff
AstralStorm: it takes time ;p