bridgman: sets his alarm clock to go off early
bridgman: notices it is already early
soreau: unplugs bridgmans alarm clock while he's not looking
spstarr: bridgman: heh
spstarr: bridgman: im glad its not (supposed) to be snowing thursday, have an interview in the loo
spstarr: glisse: im gonna stay up late, maybe i'll take a few hour sleep and get up your time so I can test stuff.
bridgman: in the loo ? like the toilet ?
spstarr: hehe
spstarr: well, I dont think that city would call it that
spstarr: smirks
spstarr: hello google, I know you're logging this ;p
dougmencken: builds a kernel with patch now
dmb: spstarr, your talking to the googles now?
spstarr: no, but google is logging you :)
dmb: Cheese! Your on candid google!
spstarr: this channel is logged
spstarr: :)
dmb: spstarr, btw, jobs are overrated, don't get one
spstarr: heh
dmb: just ask bridgman
spstarr: ok, you can support me then :)
spstarr: the channel logging is nice because i can tell glisse all the issues im having and 6 hours or so later i'll see a response of some sorts
spstarr: is pushing the poor KMS codebase to breaking :/
Tommeh: Wooohooo.. 3D back again.
Tommeh: All by disabling KMS :(
twnqx: hi guys
twnqx: i found an ... interesting yet inconvenient ... problem with git ddx and 2.6.33-rc7 KMS
twnqx: when i try to start filezilla, my X "crashes"
twnqx: nothing in xorg log, nothing in syslog
glisse: what do you mean by crash ?
glisse: the computer doesn't respond at all ?
twnqx: well... rejects keyboard/mouse, screen slowly fades to white
glisse: can you ssh in ?
twnqx: ACPI events make it through, though, i can suspend/resume
twnqx: but on resume screens fades to white again
twnqx: (that fade to white is something i've encountered since forever on every radeon powered laptop i'Ve ever used...)
glisse: this is gpu lockup
twnqx: glisse: not from here, i'm only online on 3.5G
twnqx: and no other comp around
twnqx: assuming i could ssh in, what would you want me to look for? i might borrow a colleague's laptop
glisse: well look at dmesg and also dump files in /sys/kernel/debug/dri/0/ and attach them to a bug
glisse: don't worry about radeon_ib_* files
twnqx: nothing in dmesg (syslog is complete, and contains kernel messages in my setup)
twnqx: i don't have /sys/kernel/debug
glisse: what do you do have the crash ?
glisse: hard reboot the computer ?
twnqx: start filezilla.
twnqx: oh
twnqx: to get it working again?
glisse: yeah
glisse: after
glisse: not have
twnqx: looked like i can suspend/resume/use open console on vty1/ype "reboot"
glisse: so you definitly should have somethings in /var/log/message
glisse: if you don't have /sys/kernel/debug this means you are not mounting debugfs
glisse: and we need debugfs to debug radeon
twnqx: ok
twnqx: manual mount=
glisse: debugfs /sys/kernel/debug debugfs defaults 0 0
glisse: fstab line
twnqx: ah, no debugfs in proc/filesystems
twnqx: guess i need to recompile first
twnqx: brb... hopefully with the logs
twnqx: right...
twnqx: glisse: http://digadd.de/debug.tgz - contains Xorg.0.log (sadly not maximum verbose), dmesg, and all files in /sys/kernel/debug/dri
twnqx: oh wait...
AndrewR: heh, at least one user asked for DRI on mach64 ... and as you can guess, 1280x1024x16 doesn't fit (with dri1) into 8 mb of VRAM ... (2.5 front + 2.5 back + 2.5 z = 7.5 Mb)
twnqx: http://digadd.de/debug.tbz2
glisse: twnqx: open a bug and attach them there
twnqx: ok
twnqx: glisse: i guess it's a 2D bug?
glisse: open it against ddx
xming: hmm mach4, I might have one of those and an aiw
xming: but my mach64 is only 2MB IIRC
AndrewR: and it was even pci mach64, so no AGP texturing ..but at least windowed dri2 should still be possible ...if someone rewrites kernel driver and everything above it .....
AndrewR: last Re: Removal of mach64 on dri-devel ....
twnqx: problem...
twnqx: i don't have a wiki login, and thunderbird kills X as well.
twnqx: :P
twnqx: good i have mutt...
xming: my mach64 was top of the bill at that time
AndrewR: xming, i guess people with early matrox cards was very happy with their costly toys at that time, too ...(saw g400 in action once, was impressed ...~10 years ago)
twnqx: glisse: in which category should i file it, straight under xorg?
xming: I haven't heard about matrox at that time, neither voodoo nor nVidia, just trident and ATI
xming: it's almost 20 years ago
glisse: twnqx: ddx xf86-video-ati
evil_core: lol, no 20 years ago ;)
evil_core: 20 years ago were hercules
xming: evil_core: hercules/cga are much older
AndrewR: http://marc.info/?l=dri-devel&m=110773733200731&w=2 (old r100 beats my rv280 @ current mesa ...i never saw >60 fps even in 640x480)
xming: Released: 1994 accoring to wikipedia, that's 16 years
xming: Port: ISA, VLB, PCI
AndrewR: stupid question ... if Memory Controller configured for DDR, but actually has SDRAM connected to it ... will it work at all?
twnqx: glisse: straight on https://bugs.freedesktop.org/enter_bug.cgi ? can't find the ddx there
xming: there wasn't an AGP edition, but there was a VLB one :p
jcristau: twnqx: https://bugs.freedesktop.org/enter_bug.cgi?product=xorg&component=Driver/radeon
twnqx: thanks
AndrewR: xming, imagine dri/OpenGL over ISA ... (but seriously, i think on old cpu even small accel on-card will help .... not sure abot p4 + mach64 config ...for 2d, or 320x240 3d)
AndrewR: xming, http://www.mail-archive.com/dri-devel@lists.sourceforge.net/msg04072.html (if we still talk about mach64 ...)
xming: AndrewR: I ran 1152x1024 on that card, played tons of doom
xming: AndrewR: well doom wasn't at that resolution, it was 320x240 :p
AndrewR: xming, i remember big speed boost when i swap iSA card with VLB one ...and now i have prboom for some d2 or even openGL benchmark ... not actually playing it....
AndrewR: xming, *2d
xming: mine was pci with 2mb, pff, now I have 512mb on my card, that's *256 in 16 years
AndrewR: xming, and all this memory mostly used for pictures, 3d destops and games ..... (but i remember something about more serious use)
AndrewR: http://archive.netbsd.se/?ml=dri-users&a=2008-01&t=6036308
agi: hi all, I've got a problem I can't trace. Two laptops, both using HD4570, and fglrx. Both load fbcon and radeon. But in one of them both modules remain unused, whereas in the other when radeon gets load, udev switches to framebuffer (thus breaking Xorg/fglrx). What is making the second laptop activate the fb console?
agi: maybe the question should be, how can I avoid radeon module loading from generating a framebuffer console apart from blacklisting it?
adamk: agi: Huh? You can't use radeon and fglrx at the same time. Peiod./
agi: I know
agi: but for some reason I ignore
agi: it is being used in one of the laptops
adamk: radeon should not be getting loaded unless your distribution loads it by default or Xorg loads it. If you don't want it loaded, blacklist it.
agi: adamk: yeah, blacklisting works. I was trying to figure what the laptop user did to make it behave diferently from the other one
adamk: Perhaps the radeon module on the laptop is too old for the GPU.
suokko: glisse, airlied: cs checker doesn't allow for HOSTDATA_BLT that would be used by XV dma for image upload
glisse: suokko: best is to convet xv
suokko: glisse: Is DMA packets allowed?
glisse: suokko: we should use normal blit
glisse: like in exa
suokko: ok
suokko: I call same function that is there then.
suokko: btw, XV as been all this time broken in KMS and none as noticed anything :/
xming: I get this just by running glxgears and move the mouse around a bit
xming: radeon_ring_lock radeon_ib_schedule radeon_cs_ioct195.2 msec 0.9 %
xming: suokko: would glxgears be too much for the GPU? Yesterdat you commented that it may be that GPU was not fast enought to do its work
suokko: glisse: Can you reproduce xming's problem?
suokko: There is something going badly wrong
glisse: xming: cpu ?
twnqx: checks on his bug report
glisse: twnqx: what is the bug id ?
twnqx: 26491, and yes, i was kidding :P
suokko: glisse: What would happen if irqs were off for a few milliseconds?
suokko: Just wondering because spstarr irqso off report had one 0.9ms period with irqsoff from __iommu_flush_iotlb
glisse: yeah irq off is bad
glisse: wonder why they are of for so long
glisse: is there a clue in the stat ?
glisse: haven't looked at them yet
xming: glisse: rv670/3850 agp
glisse: xming: cpu :)
suokko: Only tht __iommu_flush_iotlb called _raw_spin_lock_irqsave
suokko: And then for some reason where in spin_lock contex for 0.9ms
xming: glisse: amd x2 2.4Ghz
AndrewR: suokko, xv broken with KMS? For me it works ....
mcgregor: so it does here
mcgregor: and it never stopped working as far as I know
suokko: AndrewR: Can you play 720p without tearing?
suokko: with r200 card?
mcgregor: oh it broke on r200 only?
suokko: r600 has different path
AndrewR: suokko, probably not, i don't have so much CPU for decoding it
AndrewR: suokko, i have few 720p samples, but they h264, so .....
AndrewR: suokko, *but they are. And few 1080i mpeg2 and 1440xsomething old wmv3 trailers ...
suokko: AndrewR: I can play h264 without tearing if I first make saurbraten crash
suokko: That somehow fixes xv notto use memmove
suokko: And I just don't know why it happens
AndrewR: suokko, can you try x11perf -shmput500 or -putimage500 ? For me they are dog slow with KMS...
suokko: Without cash memmove has 40% CPU time in sysprof
AndrewR: suokko, so, i can call -vo x11 not usable as is ;)
mcgregor: AndrewR, 3200 reps @ 1.7703 msec ( 565.0/sec): ShmPutImage 500x500 square ; 16000 trep @ 1.8028 msec ( 555.0/sec): ShmPutImage 500x500 square
suokko: 80 reps @ 77.5731 msec ( 12.9/sec): PutImage 500x500 square
AndrewR: 120 reps @ 61.7087 msec ( 16.2/sec): ShmPutImage 500x500 square
mcgregor: 8000 trep @ 4.0336 msec ( 248.0/sec): PutImage 500x500 square
AndrewR: mcgregor, wins
suokko: memmove loses
glisse: xming: you build your kernel yourself ?
mcgregor: I use a rv730 mobility
AndrewR: 80 reps @ 81.4803 msec ( 12.3/sec): PutImage 500x500 square
AndrewR: suokko, i always blamed my .config ....
xming: glisse: yes
glisse: xming: do you have bug opened for your issue ?
glisse: if no can you send your kernel config
suokko: AndrewR: Yo ushould profile it ;)
xming: glisse: no, I just mostly piggyback to spstarr's issue (stalls)
glisse: xming: ok attach your config there
glisse: http://bugs.freedesktop.org/show_bug.cgi?id=26491
glisse: sorry wrong bug
glisse: http://bugs.freedesktop.org/show_bug.cgi?id=26491
glisse: https://bugs.freedesktop.org/show_bug.cgi?id=26087
xming: glisse: ok will do
AndrewR: suokko, 241620 81.7250 vmlinux
AndrewR: pastebin.ca is busy
suokko: AndrewR: Can you get debug symbols for yo ur kernel?
AndrewR: suokko, opreport --symbols ? it works, there was additional flag for modules ....
suokko: AndrewR: yes. Yo uhve to give modules path to get symbols for kernel modules
suokko: AndrewR: try this "alias upload='curl -F sprunge=@- sprunge.us'"
suokko: then piepe to upload what ever you want to pastebin
AndrewR: suokko, this is just opreport http://pastebin.ca/1791314
AndrewR: suokko, may be i should shut down seamonkey- first ....
AndrewR: *even must. But i remember this bug even at fresh X start
xming: glisse: done
suokko: AndrewR: Can you get per symbol stats?
AndrewR: suokko, http://pastebin.ca/1791318
AndrewR: resets oprofil;e data and kill mozilla
AndrewR: suokko, http://pastebin.ca/1791330
AndrewR: suokko, 76989 20.7457 vmlinux Xorg s_show same thing slows down nouveau .. probably .. this is reason why i think my kernel .config is bad (or buste in some way)
AndrewR: suokko, this s_show ruined whole show ....
AndrewR: suokko, i tried to disable most tracing functions, but it still shows up in profiles
AndrewR: suokko, nouvea in my context = gallium on nv40 ....2 d side was totally fine, up to 250 images in x11perf --putimage500
AndrewR: *nouveau
Ivanovic: is it intentional that in here still only those registered at nickserv can talk?
Ivanovic: as in: airlied, agd5f, MrCooper or ajax could get OP for themselves and remove the +q (quiet) entry for $~a by using "/mode #radeon -q $~a"
MostAwesomeDude: Or you could register.
Ivanovic: MostAwesomeDude: i am registered as you might see at my hostmask
MostAwesomeDude: Ivanovic: I know.
Ivanovic: MostAwesomeDude: the matter is that users might try to post and have no idea why noone does reply
Ivanovic: since quiet is, IIRC, transparent to the user
mcgregor: IMHO Ivanovic is very right
MostAwesomeDude: Well, what do you want me to do?
Ivanovic: there was just a user in #openpandora already frustrated with his irc client
AndrewR: Ivanovic, i have message if i tried to talk unregistered
Ivanovic: MostAwesomeDude: can you get OP?
MostAwesomeDude: I could cynically note that nearly every user can be satisfied by the contents of /topic...
MostAwesomeDude: Or I could practically note that I have no ops in here.
Ivanovic: once you have OP, just run "/mode #radeon -q $~a"
Ivanovic: exactly
MostAwesomeDude: Ivanovic: I know how to IRC, thank you very much.
MostAwesomeDude: And so do you, since you got the ops list.
Ivanovic: like i said, in general only DJWillis has the permission to do so
MostAwesomeDude: And hopefully read it and noted that I'm not on it.
Ivanovic: (plus the freenode staff of course)
MostAwesomeDude: I have the ability to summon freenode staff, but that's overkill. Just sit tight. Or, y'know, continue to be unaffected.
Ivanovic: sorry, djwillis was a different chan, the ones i highlighted with my request are the ones in here that are able to easily get op access and change the settings (if desired)
qburke: i'm in no mans land. no-one seems to know what i need. i want to set the resolution of radeondrmfb to 1024x768. is this possible ?
mcgregor: yeah and thats the point.. you should only ask those in the access list and nobody else since those are in charge about such things
BioTube: qburke: add video=1024x768 to the kernel command line
qburke: BioTube: ah. nice
AndrewR: hm .... on dri.freedesktop.org wiki gives me this error "Sorry, can not save page because ".info" is not allowed in this wiki."
Jonimus: Woo w/e changed between 2.6.33-rc5 and rc7 greatly improved my laptops performance
Jonimus: at least from the basic testing I've done so far
Jonimus: either way it looks promising
Tommeh: Nice :)
Tommeh: fancies trying this.
twnqx: Jonimus: mind starting filezilla or thunderbird for a small test?
Jonimus: twnqx: sure...
Jonimus: twnqx: both opened fine on my HD4670 Mobile
twnqx: meh
twnqx: so it's either only my rv635
twnqx: or a library...
Jonimus: I'd say some other package must have been corrupted
twnqx: but i only changed ddx and kernel
twnqx: Jonimus: using KMS?
Jonimus: twnqx: yup
twnqx: great.
twnqx: which libdrm and mesa version?
Jonimus: both from git about a day or two old
twnqx: hm
twnqx: i could give git libdrm a try
Jonimus: my desktop has the newest of both and 2.6.33-rc6 and both filezilla and Thunderbird work fine
Jonimus: thats with a HD4850
Jonimus: I've built rc7 for it but I haven't rebooted into it yet
twnqx: oh
twnqx: well, i went from 2.6.31.6 to 33rc7 :P
Jonimus: heh lol
twnqx: all .32 crashed for me with radeon
Jonimus: but it still sounds like something is broken library wise, what error do you get when you run either of them from the terminal
twnqx: none
twnqx: i also get no errors in dmesg, and none in xorg.log
twnqx: and i know too little to make use of the debug info :)
twnqx: right... new libdrm... do i need to recompile the ddx?
BioTube: the interface hasn't changed since 2.4.17
twnqx: ok, thanks
twnqx: is going to crash his laptop one more time
spstarr: glisse: afternoon
spstarr: glisse: I can provide more debug as needed
AndrewR: malc.info was not allowed on Wiki ... http://dri.freedesktop.org/wiki/AndrewRandrianasulu - doest it look good/half-useful , as start ?
suokko: AndrewR: You should try to get sysprof from git and use it for profilin. it gives a lot mre mening full info
suokko: x11perf problem with 500x500 is that ttm is all the time allocating bos and has to put them to wc
suokko: So it would be a lot faster if we had already enough wc pages to use them without allocating and freeing them all the time
dougmencken: airlied, ping
spstarr: hello suokko
suokko: hi
spstarr: has glisse been able to reproduce any of the stalls?
suokko: MrCooper: Can you explain me why there is CopyMungedData in video code?
MrCooper: suokko: not 100% sure but I think it converts from planar to packed or something like that
suokko: That function and CopyData has to be rewriten for KMS :/ I'm jsut trying to understand how to do it
agd5f: suokko: yeah converts from planar to packed while uploading
MrCooper: 'has to be rewritten' why?
MrCooper: not sure I'm hitting CopyMungedData much, but CopyData seems to be working just fine
suokko: MrCooper: For KMS it is not accelerated
suokko: It is just call to memmoe which has sometimes horrible performance
MrCooper: it should be no different from UMS
suokko: And if I simple enable old UMS accerlation code kernel doesn't allow HOSTDATA_BLT packet
MrCooper: right, I guess I mean 'UMS without DMAForXv'
suokko: And glisse saied better to rewrite Xv to what exa is doing
agd5f: suokko: just cut and paste *UploadToScreenCS from exa
MrCooper: s/cut and paste/factor out/ :)
agd5f: or eve better abstract the actual upload and add a wrapper for UTS and Xv upload
suokko: agd5f: That is the plan but I need to pass bos for it instead of pointers
suokko: Kernel won't like raw offsets without relocation information
agd5f: suokko: you have the bos in RADEONPortPrivPtr
agd5f: suokko: src_bo = pPriv->src_bo[pPriv->currentBuffer]; dst_bo = radeon_get_pixmap_bo(pPixmap);
suokko: yes. Maybe that is simplest solution that I just pass the PortPrivPtr to eerywhere and pointers are invalid in kms case
agd5f: suokko: just pass the bos
suokko: I was jsut wondering how to o it without large number of ifdefs
agd5f: an make it kms specific
agd5f: ums already has a fast path
MrCooper: suokko: BTW, I'm not sure a blit (hostdata or not) is necessarily faster than CPU writes to VRAM with write-combining
MrCooper: might be worth making some measurements before spending too much effort on this
suokko: MrCooper: That is the funny part
suokko: Because if I use xv in freshly booted system it is very slow
suokko: But If I first make saurbraten to crash and then try to use xv CPU copy is very fast
AndrewR: suokko, "Kernel Performance Events And Counters" just blank page for me , in kernel's menuconfig
suokko: AndrewR: Yo uhave to enable kernel hacking first
AndrewR: suokko, enabled ...
MrCooper: suokko: try specifying GTT or VRAM explicitly for the radeon_bo_open() call in radeon_legacy_allocate_memory()
suokko: MrCooper: And he yo utried to use DMA engine in card for transfer?
MrCooper: suokko: otherwise the BO will probably start out in RAM and be bound to GTT or copied to VRAM only for the blit
MrCooper: suokko: I haven't
suokko: I think advantage in dma engine would be that we could make dma transfer run in parallel while pushing others commands to GPU
suokko: So we could in thoery have for Xv cpu doing decode, dma doing transfer to GPU and GPU doing post processing in parallel
Ronis_BR: I'm getting font corruption with radeon+KMS, is anyone having this also?
MrCooper: possibly
dougmencken: Ronis_BR, where? in tilda?
Ronis_BR: dougmencken: desktop, everywhere
Ronis_BR: dougmencken: it happens sometimes, like after window resizing
Ronis_BR: dougmencken: with compositing enable
dougmencken: uses metacity
adamk: metacity is perfectly capable of doing compositing.
AndrewR: hm , gallium-cylindrical-wrap branch cherry-picked into master ... may be MAD want to show us how to use it (and what it was, in the first place)
thansen: there are 3 drivers for ati correct? ati,radeonhd, and fglrx?
mcgregor: hmm because of -> delete mode 100644 src/glx/x11/Makefile mesa doesnt compile anymore?
chithead: thansen: if you discount historical xf86-video-avivo
AndrewR: http://140.130.175.70/html/canvas/3DCanvasDocumentation/tutorialtextures.htm -? sorry, i only saw something about this in amd r5xx manual ... not sure for what kind of apps it will be useful ....or was useful.
thansen: chithead: right. and sometime ati is referred to as simply 'radeon'?
BioTube: that's the real driver
chithead: xf86-video-ati used to include mach64, r128 and radeon drivers. now only radeon
BioTube: 'ati' is technically a metadriver that selects one of what chithead mentioned
BioTube: but mach64 and r128 were removed from the repo
thansen: ok
thansen: and on the mesa side of things, there is both dri and gallium support for radeon?
BioTube: gallium only has support for r300-r500 at the moment
BioTube: but classic mesa supports everything before evergreen
thansen: BioTube: ok, I have an r300 (X1400 mobile). Should I try the gallium or not waste me time?
BioTube: r300g's not stable yet
BioTube: so unless you *really* need shader support, stick with classic
thansen: will be buying an evergreen soon
thansen: BioTube: just compiz..no gaming or anything else
BioTube: classic should do you
thansen: it's a little sluggish, but livable
thansen: it's on a dell 1705 running 1440x900...I believe the laptop has dual link dvi and I'm interested in powering a 30 inch
thansen: I wonder how the performance degrades at a higher res (2560x1600)
BioTube: the texture limit's something like 2048, so compiz might have trouble
thansen: BioTube: would I run into that same issue with newer cards?
suokko: MrCooper: That placement was nice catch. Problem is that memmove is very slow to vram but fat to GTT
suokko: But wht would happen in saurbraten crash that would prevent Xv from using vram?
taiu: x1400 is r500, so the limit should be 4096 afaik
BioTube: thansen: on r600 and newer, the bigger problem is mesa's built-in limit
agd5f: suokko: lots of textures in vram
thansen: taiu: glxinfo is reporting r300 for this card (if I'm reading it right)
BioTube: r300-r500 use the same driver
suokko: Maybe we should handle application crash so that everything gets freed.
markinfo: i have kompiled radeon KMS in kernel - and upon the start it freezes for a minute and then boots and dmesg shows:
markinfo: [ 18.468832] platform radeon_cp.0: firmware: requesting radeon/R520_cp.bin
markinfo: [ 78.468040] radeon_cp: Failed to load firmware "radeon/R520_cp.bin"
taiu: thansen: driver is r300 for all these, x1400 should be chip r515 or mth
agd5f: markinfo: you need to install the ucode. if you are using debian, you need the linux-firmware package
BioTube: markinfo: if the module's built into the kernel, the firmware needs to be as well
markinfo: agd5f, i have firmware - but there is problem if it iscompiled not as a modul but direct in kernel - where to put radeon/R520_cp.bin ?
taiu: agd5f: maybe you can find out smth: etqw has texcoord (2 comps) as GL_SHORT, and these seem to work with SQ_NUM_FORMAT_SCALED ..
MrCooper: suokko: all the BOs allocated by a process should already get freed when it dies
taiu: agd5f: but in sauerbraten vertex (3 comps) does still not work
markinfo: BioTube, where to put it?
BioTube: markinfo: it needs to be built into the kernel
BioTube: CONFIG_FIRMWARE_IN_KERNEL needs to be enabled
taiu: agd5f: somehow it starts to work if i put surface format with 4 comps FMT_16_16_16_16 ...
suokko: MrCooper: Maybe there is some fragmentation then so there is no space for large video textures. (I was testing 720p so it requires quite large spaces)
markinfo: BioTube, well ... # CONFIG_FIRMWARE_IN_KERNEL is not set
BioTube: then you need to recompile with it set
markinfo: BioTube, Do i need to put firmware somewhere before compilation? or is it already in kernel source package?
BioTube: it's in the firmware/ directory of the kernel source
agd5f: taiu: the 3 component formats have some limitations IIRC
agd5f: taiu: we should probably avoid them
taiu: agd5f: so special case SHORT in vertex resource?
markinfo: BioTube, no - in the directory /usr/src/linux-source-2.6.32/firmware is nothing like R520_cp.bin or radeon. But it is in /lib/firmware/radeon Shoul i copy it to the kernel source?
BioTube: no
BioTube: it needs to be in firmware/radeon
agd5f: taiu: I don't think the int to float conversion in the vertex fetch works on some chips.
markinfo: i do not believe - where? in my system in /lib/firmware/radeon or in a kernel source in /usr/src/linux-source-2.6.32/firmware ?
BioTube: the firmware should be in source/firmware/radeon
markinfo: BioTube, there is only a few things - not a radeon - but iI have kernel source package from debian - maybe they have deleted it.
BioTube: probably
taiu: well, we can also use convertattrib, that did work ok for the 2 above cases
svenstaro: Does anybody else see a big performance hit doing render-to-texture?
suokko: svenstaro: Big or not big but there is qutie many bugs related to fbos
spstarr: suokko: http://marc.info/?l=dri-devel&m=126569460126246&w=2
spstarr: some locking changes in the drm
svenstaro: suokko: Performance is equally bad using RTT copy instead of FBO
suokko: svenstaro: Maybe mesa is rendering to GTT which might be slow
svenstaro: GTT?
suokko: svenstaro: http://dri.freedesktop.org/wiki/GART
svenstaro: Uh, I see
svenstaro: Any chance this magically goes away with DRI2 and KMS
svenstaro: ?
suokko: I have no idea if it is fixed in dri2 code.
FIReun: oh boy, I wonder how well this chip will be supported in the linux world -- http://arstechnica.com/business/news/2010/02/amd-reveals-fusion-cpugpu-to-challege-intel-in-laptops.ars
qburke: BioTube: yeah i tried the video=1024x768 on the kernel command line for radeondrmfb. no dice. but 640x480, 800x600, 1280x1024 & 1600x1200 all worked. what is strange is that the mode switch to 1024x768 for gdm worked fine. and here i am in X at 1024x768
svenstaro: suokko: Any way I can help?
suokko: svenstaro: You can add code to monitor placement of texture wihch is rendering target
dougmencken: sorry, may be off-topic, but I need benh; benh, hi! may I poke you? I have a question on snd-powermac driver
svenstaro: suokko: You mean I should basically profile the driver?
suokko: svenstaro: Not exactly profile but jsut debug what happens there :)
mentor: Is it just me, or are color indexes not working in master?
xming: I just bought a new monitor (with different resolution than the old one), if I just pluu out the old one and plugin the new one, would the resolution change autogimatically?
Jonimus: xming: not likely
adamk: I do not believe so. I thin you need to run 'xrandr' to adjust the it.
Jonimus: xrandr --auto should fix that though
xming: ok let's try :D
xming: is unpacking
twnqx: so, yeah.. not sure if my bug is kernel related any more
twnqx: i hit it in... 3.6.32.4, 2.6.32.8, 2.6.33-rc1, 2.6.33-rc4, 2.6.33-rc6, 2.6.33-rc7
twnqx: 2.6.32.4*
xming: 300 euro for a 24" LED backlitghed, I think it's a good deal
twnqx: anyway, i insist that thunderbird must not lock up the gpu
markinfo: Biotube - i have recompiled kernel with firmware inclusive - but still the kernel finds any firmware: radeon_cp: Failed to load firmware "radeon/R520_cp.bin"
markinfo: is this correct? http://85.126.193.68/marek/data/kernel-config.png
markinfo: should not be "prevent firmware be built" be unchecked?
markinfo: What is "External firmware blobs to build into the kernel binary" ...it cannont be checked.
spstarr: huh
spstarr: HD 3650 (RV620)
spstarr: I thought it was the RV635?
spstarr: unless my desktop HD 3650 == RV620 and laptop HD 3650/FireGL 5700 is RV635?
spstarr: (desktop mobile PCIe card)
twnqx: 01:00.0 VGA compatible controller: ATI Technologies Inc Mobility Radeon HD 3650
spstarr: twnqx: desktop or laptop
twnqx: laptop
spstarr: what is subvendor ID
xming: omg it's so thin and light and so big, monitor with a ext. power brick, hehe
xming: xrand doesn't help, still lists the old reso
spstarr: I have a Lenovo W500
twnqx: 1002:9591 - ubsystem: 17aa:211
twnqx: lenovo T500
twnqx: 17aa:2117
spstarr: but there is confusion since it really is a FireGL V5700
spstarr: as long as the drm and DRI properly adjust to take advantage of the FireGL part that'll be good
twnqx: [ 6.151773] platform radeon_cp.0: firmware: requesting radeon/RV635_pfp.bin
twnqx: driver loads rv635 parts...
spstarr: yeah, but Phoronix must be wrong in their article
spstarr: http://www.phoronix.com/scan.php?page=article&item=ati_r600_mesa_3d&num=1
spstarr: so maybe the RV620 really is a true HD 3650 onlyy
spstarr: and a RV635 is FireGL?
spstarr: twnqx: if you have windows on it, what does it say? FireGL or HD 3650?
twnqx: uh, i don't....
spstarr: a recent BIOS upgrade changes the PCIID info somewhere
spstarr: because people were complaining that some apps require FireGL certification and that Windows was only showing HD 3650
twnqx: http://www.thinkwiki.org/wiki/Category:T500 according to thinkwiki HD3650
spstarr: so yours is a 3650 only
spstarr: im still not sure how we can distinguish them?
spstarr: I guess VRAM size?
spstarr: twnqx: pastebin your lspci -vv
spstarr: wanna see if there is a different in info
twnqx: http://pastebin.com/d1df167b9
spstarr: oh you bought the Intel Turbo Memory thing?
twnqx: ... it has that?
twnqx: see how much i know..
twnqx: can linux do anything with it? :P
spstarr: im not sure
twnqx: i only cared for highres display and enough mem/cpu
suokko: twnqx: I guess you could at least use the turbo memory as a high speed swap ;)
spstarr: http://www.thinkwiki.org/wiki/Intel%C2%AE_Turbo_Memory_hard_drive_cache
spstarr: you can buy it as an addon
spstarr: i didn't cause Linux can't use it(?) yet
spstarr: I went with the W500 cause of 512MB VRAM and auch
spstarr: such
spstarr: can never have enough vram
spstarr: need more than 1GB +
twnqx: actually i don't really care about 3D on linux, so 32MB vram would be enough for me :P
twnqx: (unless we get vaapi support in some day)
spstarr: I hope in future as GPUCPUs (APUs) become the norm we will have huge memory for vram
glisse: what we need os
glisse: is virtual gpu memory
spstarr: glisse: hey
spstarr: glisse: any stuff for me to test?
glisse: no have been working on other stuff
spstarr: ok
spstarr: twnqx: you can use that as flash drive, but people say it only does 100,000 writes... so use for read only stuff.
twnqx: well...
twnqx: i'm considering putting a 160G flash drive in anyway
agd5f: spstarr: hd36xx is rv635, hd34xx is rv620
twnqx: so... with KMS, how likely is it that something else but the kernel modul cause GPU stalls?
twnqx: +e, +s
Ampheus: does the new code in drm-radeon-testing mean i can let my computer automatically slow my fans when not needed?
agd5f: twnqx: it's not he kernel per se, it's a bad command stream that hangs the GPU
spstarr: agd5f: so do we determine if the GPU is a FireGL variant vs Radeon HD?
twnqx: so the driver could still generate it?
agd5f: spstarr: we don't there's no difference programming-wise
spstarr: agd5f: well if there's more pipes on the FireGL do we enable them?
spstarr: or we dont need to know about how many we just enable all of them and see what is available?
agd5f: spstarr: it's hardcoded on the chip
agd5f: special reg you read
xming: had to reboot to get the right reso
suokko: agd5f: Can hw detect display switching in runtime?
spstarr: agd5f: oh nice
agd5f: suokko: what do you mean?
suokko: Just what xming jsut try to do
suokko: plug in new monitor to running system
spstarr: agd5f: do we read this register value right now? or not yet?
agd5f: suokko: with kms you get an event when you plug or unplug a digital monitor
agd5f: spstarr: yes
agd5f: we do
spstarr: great
suokko: xming: Sounds like you could report a bug then ;)
spstarr: glisse: how can I debug the GPU locking up with KMS in current drm-radeon-testing? I want to use KMS but can't
spstarr: since the laptop locks up good (if you have any audio playing it gets stuck in a loop)
agd5f: suokko: it doesn't change the mode. you just get an event
agd5f: your desktop environment has to do something with the event
agd5f: also you need 2.6.33
suokko: But then xrandr --auto should work?
spstarr: bad CS recording (glisse) <---
spstarr: this would help capture GPU lockup info?
spstarr: if so, how can I enable and give you info ?
agd5f: should, although, I don't know if it changes the mode automatically if the output hasn't been turned off to avoid turning off your exiting setup
agd5f: xrandr --output XXXX --off; xrandr --output XXXX --auto should work
xming: suokko: but is it supposed work? Changing monitor with different reso and reso will change automatically (or wit xrand --auto)?
suokko: xming: Just what Alex sayed above :)
xming: suokko: sorry, I missed, just reading it
xming: agd5f: I need .33? Isn't drm-radeon-testing enough?
agd5f: xming: drm-radeon-testing is fine
xming: okee, xrandr still reports only the resolution of the old monitor
xming: I suppose I should file a bug then
xming: freeking touch sense buttons on this monitor, they activate (red leds light up) when my finger is 1 cm from them
Obscene_CNN: creepy
Neo_The_Rawhide: hahaha
spstarr: I wonder if I should get/build Piglit?
twnqx: so ummmm
twnqx: spstarr
twnqx: you have the rv635 too?
spstarr: yes
spstarr: desktop mobile and laptop modile
spstarr: mobile
twnqx: and.. your X does not crash when you start thunderbird or filezilla? :X
spstarr: only with KMS do i get GPU lockups
twnqx: i cee
spstarr: I am unable to capture the lockup though
twnqx: screen fades to white, etc?
spstarr: usually just goes black but sometimes fades to white.
twnqx: right
twnqx: so i need to turn off MKS again
twnqx: KMS
spstarr: you are using .33 + drm-radeon-testing?
spstarr: im in UMS as it does not lockup
twnqx: no, i tried haf of the kernels from 2.6.32.4 to 2.6.33-rc7
twnqx: all vanilla
spstarr: runs piglit
twnqx: spstarr: also, i don't like 2.6.33rc since i can't build virtualbox modules :(
Ampheus: does the new code in drm-radeon-testing mean i can let my computer automatically slow my fans when not needed? if so, what do i have to do to enable it?
suokko: Ampheus: modinfo radeon
suokko: I think there is some parameter for dunamic power management
Ampheus: suokko: radeon is built in here
spstarr: result: warn
spstarr: Test: glean/texture_srgb
spstarr: result: fail
spstarr: hmm
airlied: spstarr: we have a ttm cache patch, just needs finishing'
spstarr: airlied: I will test as soon as you want me to.
Ampheus: airlied: maybe you know something about my question?
xming: Obscene_CNN: !!!
agd5f: Ampheus: load radeon with dynpm=1
Ampheus: agd5f: thx
xming: Obscene_CNN: one of your patches fails with the latest drm-radeon-testing
Obscene_CNN: I figured it would happen sooner or later.
xming: Obscene_CNN: would you support drm-radeon-testing or just .33-rc
Obscene_CNN: when I have time I will update my patches to drm-radeon-testing
xming: ok thanks
twnqx: agd5f: can i do something to figure out the reasons for my GPU stalls/hangs if i can 100% reproduce them?
airlied: spstarr: oh I didn'
airlied: spstarr: oh I didn't knwo you were running AGP machines
Obscene_CNN: I have some new stuff that will help UMS on r300 and 500 cards too
xming: Obscene_CNN: just this one drm_r600_blit_kms.patch, 12th hunk
airlied: suokko: that placement thing is wierd
Obscene_CNN: okay xming
airlied: /sys/kernel/debug/dri/0/radeon_vram_mm should show the fragmentation in VRAM if its an issue
xming: spstarr: the machine on which you have stalls is AGP?
agd5f: twnqx: try and figure out what's causing the hang. try and narrow down what commands are getting sent when the hang happens and then analyse those code pathes
twnqx: well, ok, but can i log/trace this?
suokko: airlied: It is just 4x faster to write to GTT than to VRAM
suokko: hmm not 4x but 8x realy :)
suokko: 40% to 5.5%
airlied: suokko: so you confirmed in the start 3D app case it was getting a non-VRAM buffer?
airlied: wonders if some WC problem is at play
airlied: I've seen reports about a recent patch to TTM
suokko: airlied: No. I tested with clean system that if I forced GTT placement I got same performance as after saurbraten crashed
airlied: see mails from Andy Furness on dri-devel
airlied: it might be a WC not working issue
suokko: That would explain the performance difference
airlied: yeah I think we should track it down a bit more
suokko: airlied: But I'm see this problem with vanila rc5 and rc7 kernels
airlied: suokko: oh okay maybe not the same thing
airlied: it would probably be enough to start a video player and step in the DDX and use debugfs to see where the BO ends up
airlied: or at least confirming its fragmentaiton but I can't see thta eithe
airlied: since we evict all the old dead buffers
suokko: But if there is mixed saurbraten and other buffers then you just evict saurbraten buffers and leave memory with a lot of free space but not much continues free space
suokko: Or does ttm know to move obects in vram to get larger continues blocks?
airlied: suokko: it should kick stuff out to make space if they aren't in use
suokko: ok. So it shouldn't block at least
suokko: before: total: 16384, used 5517 free 10867
suokko: after: total: 16384, used 2579 free 13805
Nille02: mh how I can convert an .bin firmware ( the for IRQ ) to the ihex format for incule it in the kernel?
suokko: and there is very few reseverd blocks after while before had 85 free blocks
suokko: and a lot of reserved blocks
spstarr: hmm piglet severely locked up X but i just managed to recover in UMS
spstarr: airlied: no AGP, only the r3xx is AGP box
spstarr: airlied: is this ttm cache patch for AGP only? if so, other than powering on the 3xx and throwing Fedora rawhide on it.. no AGP right now.
spstarr: (unless I use intel GPU mode)
looonger: is it true that non kms mode uses dri1 and kms mode dri2?
spstarr: Nille02: you need not
spstarr: Nille02: the build system will add the firmware into kernel if you use menuconfig just put the firmware in firmware/radeon if thats radeon firmware
Ivanovic: looonger: yes
airlied: spstarr: it nothing to do with Intel
spstarr: airlied: just AGP specific then?
looonger: Ivanovic: that would explain why 3d apps flicker without kms
looonger: Ivanovic: is it possible to enable dri2 without kms?
Ivanovic: i don't know, but i *think* it is not possible
evil_core: hi all
evil_core: KMS Mesa sould have regression vs UMS?
evil_core: Sky in tc-elite is strange - partially random interleaved textures
evil_core: like in old cs when you go too far
Nille02: spstarr: the problem is he can't find the firmware. I have copy both to firmware/radeon
Nille02: and if I start the new kernel I get the firmare not found error
looonger: Nille02: strange, it works here
looonger: Nille02: no errors
Ivanovic: Nille02: have you configured your system to build the firmware into the kernel?
Nille02: yes
Nille02: with the both other firmares ists works fine
Ivanovic: have you set config_extra_firmware?
Ivanovic: that is, this is how the respective area of my .config looks: http://pastebin.com/m71455a83
Nille02: I don't know im currently not at home
Ivanovic: with the firmware file (the one not shipped with the kernel which is R600_rlc.bin) in /lib/firmware/radeon/ when building the kernel things are perfectly fine
Nille02: I try try it thank you
evil_core: where is Zajec?
Ivanovic: not in here
Ivanovic: :)
Neo_The_User: hi all. i have serious issues. X won't start, DRI is hosed, KMS is all messed up, I need help. /var/log/Xorg.0.log > http://neotheuser.pastebin.ca/1791847
ajax: Neo_The_User: you're missing R700.rlc
ajax: er, R700_rlc.bin i think
Neo_The_User: so fedora rawhide left that out.
airlied: yum install xorg-x11-drv-ati-firmware
ajax: dmesg probably says as much
airlied: I sohuld move it to l-f until dwmw2 wakes up
ajax: yes, you should. are you provenpackager?
airlied: yes, I added nouveau to it yesterad
ajax: high five
airlied: was being lazy since I sent th eRLC ones to dwmw for upstream
airlied: I thought I'd let the process work for once
Neo_The_User: thank you all for the help. i need to go to #fedora-qa as it says could not get repo.xml file from repository: rawhide.
suokko: Jsut checking: We should run tcl renderer even when rendering target is texture?
Neo_The_User: what is dwmw?
jcristau: *who
ajax: just what is dwmw
xming: again who
Neo_The_User: ok.. who
Neo_The_User: some fedora dude?
jcristau: Neo_The_User, meet google. it's a search engine. it has the answer to your question.
xming: I know him from the olpc
xming: actually from the callweaver project
ajax: http://lmgtfy.com/?q=dwmw
xming: he also maintain a git tree of firmwares
Neo_The_User: ahh. alright thanks for the help guys
jcristau: you're always welcome.
spreeuw: /bin/sh ../../bin/minstall ../../lib/libGL.*so* \ /usr/local/lib
spreeuw: Unknown type of argument: ../../lib/libGL.*so*
spreeuw: mesa install bug
spreeuw: hmm or my libs dinnae build
mattst88: agd5f, these two patches were sent to xorg@ instead of xf86-video-ati@, please review http://lists.freedesktop.org/archives/xorg/2010-February/049050.html
Ampheus: airlied: if you want feedback: i enabled power-management and the fan speeds up on load but doesn't slow down afterwards. i only get a lot of [drm] Requested: e: 50000 m: 80000 p: 16 [drm] Setting: e: 50000 m: 80000 p: 16
Ampheus: [drm] Requested: e: 30000 m: 30000 p: 16 [drm] Setting: e: 30000 m: 30000 p: 16 in dmesg
Ivanovic: mattst88: cool, fixes for the annoying warnings!
mattst88: yeah. I should be perfectly clear that those are not my patches (that's not my email either)
xming: while compiling the mesa git master I got
xming: r600_texstate.c: In function 'r600SetTexBuffer':
xming: r600_texstate.c:1119: error: '__DRM_TEXTURE_FORMAT_RGBA' undeclared (first use in this function)
spreeuw: xming: got that one too just now
spreeuw: there seem to be mesa commits going on
xming: spreeuw: thanks, I will wait a bit then :p
spreeuw: autogen doesnt fix it
marvin24: looks like drm-radeon-testing has some merge conflicts with current master
marvin24: atombios.h makes problems
marvin24: any solution how to fix this?
mcgregor: fails here too
mcgregor: using mesa/libdrm master
Wizzup: just came here to ask about that
mattst88: marvin24, it was rebased. This is probably what you're seeing.
agd5f: marvin24: what are you trying to merge?
agd5f: mattst88: done
Ampheus: agd5f: same for you
marvin24: drm-radeon-master into origin/master
mattst88: I just do a `git reset --hard HEAD~100` and then a `git pull` usually, but I have no idea if this is the right way to do it.
mattst88: oh, you're doing something else. Nevermind.
Ivanovic: agd5f: regarding the texture prob issue, stikonas just added some info
Ivanovic: agd5f: could be something strange in the r6xx blitting code
agd5f: Ivanovic: the blit code is only in mesa master
Ivanovic: uhm, okay
Ivanovic: then it is a really strange one...
Ivanovic: since one 7.7 user also reported the issue
Neo_The_User: firmware still isn't loading, r600_cp.bin doesn't exist and xorg-x11-drv-ati-firmware is installed
stikonas: agd5f after certaint revision in frogatto, it started working even worse
Ivanovic: the matter is just that things got worse with the latest commit
agd5f: stikonas: you said it was fixed in a newer version of the app
stikonas: no, it wasn't
Ivanovic: agd5f: he meant it got worse, since before you could at least see the frog and two doors in the main menu, those are now gone, too
stikonas: sorry, if my English is not clear enough
stikonas: I'm not a native speaker, though I live in UK now :)
agd5f: Ivanovic, stikonas: does it work any better/worse with mesa 7.7 branch?
Ivanovic: lets install that one and prey that things still work with it...
Ivanovic: give me some mins to build the packages and restart xorg
Ivanovic: or is a restart of xorg not required to make a different mesa version take effect?
Neo_The_User: should I try chmod +x /lib/firmware/radeon/* ?
agd5f: Ivanovic: don't need to restart
Ivanovic: Neo_The_User: uhm, no
Ivanovic: Neo_The_User: http://wiki.x.org/wiki/radeonBuildHowTo#TroubleshootingExtraFirmwareforR600.2BAC8-R700
Neo_The_User: i have them already
Neo_The_User: xorg-x11-drv-ati-firmware is installed
agd5f: Neo_The_User: need it update your initrd if you are using one
Neo_The_User: ... and back to #fedora. thanks
Ivanovic: agd5f: no visible difference for me in frogatto r1712
Ivanovic: agd5f: that with both, git master and mesa 7.7 (release version) it looks identical
agd5f: Ivanovic: ok. so probably not the blit code
agd5f: Ivanovic: if you use non-float values for vertex attributes that may be a problem
Ivanovic: not my code, no idea what is used (i only test frogatto as testbase for a possible migration of wesnoth to opengl to check how well things do currently work speedwise)
Ivanovic: btw this commit breaks current compilation: http://cgit.freedesktop.org/mesa/mesa/diff/src/mesa/drivers/dri/r600/r600_texstate.c?id=debf00e5fc3828f63e0f99d72c7fa6cd6ce012c5
MostAwesomeDude: soreau: I just made a slight adjustment to r300g; lemme know if the compiz corruption is lessened or gone.
airlied: MostAwesomeDude: no asserts please
airlied: since in AIGLX it kills the X server with no logs
MostAwesomeDude: airlied: I'm pretty sure I actually removed an assert.
MostAwesomeDude: Oh, crap, the shaders. Sorry.
MostAwesomeDude: Yeah, we still have no good way to fail a shader.
airlied: just pretend you wrote it or something
suokko: MostAwesomeDude: What gl call we are in when shader is compiled?
MostAwesomeDude: suokko: Not sure. Depends.
MostAwesomeDude: airlied: Well, there's like five other asserts that will kill anything with ILLEGAL_OPCODE, so this is just bailing slightly earlier.
suokko: Maybe we could just use _mesa_error
MostAwesomeDude: There *is* a chance that the offending opcode will get optimized out, but it's not likely.
MostAwesomeDude: suokko: This is Gallium-land.
spreeuw: huh google knows nothing about "DRM_TEXTURE_FORMAT_RGBA"
spreeuw: is this a typo?
suokko: Isn't there something similar in gallium?
agd5f: spreeuw: http://cgit.freedesktop.org/mesa/mesa/commit/?id=debf00e5fc3828f63e0f99d72c7fa6cd6ce012c5
MostAwesomeDude: suokko: Yes, but.
spreeuw: so do I need newer headers or anything?
MostAwesomeDude: suokko: Gallium API currently has no provision for failed shaders. We all agree that something should be doable, but we haven't decided what.
spreeuw: or is it all in tree?
spreeuw: mesa doesnt build anymore for me
MostAwesomeDude: airlied: I was playing with r300g-glsl from nha , and I think it's probably mergeable.
spreeuw: so those headers are not in head yet
sroland: agd5f: what's up with anisotropic filtering in the r600 docs?
airlied: MostAwesomeDude: if nha is happy and piglit doesn't get worse than go for it
MostAwesomeDude: sroland: Is it missing? It's missing in the other docs, too.
MostAwesomeDude: airlied: Yeah, that's the thing.
MostAwesomeDude: Also one of the patches, for constant folding, is already fairly implemented Gallium-side, so I'm not sure if it should get pulled in.
airlied: if it helps classic it might be needed
Ivanovic: stikonas, agd5f: the build issues and the likes are now fixed in frogatto r1715, that is you can build things with a plain call of make if all deps are installed
Ivanovic: this is the "basically nothing visible"-edition
suokko: MostAwesomeDude: Does r300 pass LIT 0^0 = 1 test in glean/vertProg?
MostAwesomeDude: suokko: Almost certainly not.
MostAwesomeDude: Vert shaders on r300 are 0**0 = NaN
airlied: suokko: no
airlied: MostAwesomeDude: they are 0^ anything = 0
airlied: not NaN
suokko: Output is 0 for r200
MostAwesomeDude: airlied: Really? I've got this "Vertex shaders evaluate 0^0 as NaN." from the wiki.
MostAwesomeDude: Also "R300 fragment shaders evaluate 0^0 as NaN."
airlied: the R5xx docs say different
airlied: search for ME_POWER_FUNC_ME
airlied: FUNC_FF even
MostAwesomeDude: I know we have a magic flag on r500 for frag shaders.
Ivanovic: agd5f: just talked to jetrel (he is online in irc, though he tends to not join too many chans...), he said that they intentionally use shorts for the vertex attributes since this is just the precision required
Ivanovic: agd5f: this should explain the reason for the problems, right?
Ivanovic: the reason for this is the reduced memory bandwidth compared to using floats
agd5f: Ivanovic: yes. they are broken right now in git
Ivanovic: okay
airlied: MostAwesomeDude: I think that applies to all the power operations
airlied: its annoying since x ^ 0 give 1.
Ivanovic: agd5f: want me to add this as comment to the bugreport or will you take care of it? (that is: i would just paste this part of the changelog)
airlied: but the GL spec is explicit on 0^0=1
MostAwesomeDude: airlied: Yeah, 0**0 has frustrated just about everybody over the years. :3
agd5f: Ivanovic: yes please
airlied: suokko, MostAwesomeDude : its one of the reasons I'd like to have someone add some sort of annotations to piglit tests
airlied: so we can document places we know diverge but don't care about
MostAwesomeDude: airlied: eosie reported that a simple glDisable(GL_DITHER) massively improves reports on a couple tests.
airlied: probably should do that in the test alright
airlied: since I'm not sure how well definde dithering is
MostAwesomeDude: It's not.
MostAwesomeDude: Dithering's implementation-dependent, optional, and on by default.
MostAwesomeDude: It's also not defined in terms of FB depth.
suokko: airlied: I was thikning more like automatic skipping for hw that can't pass the test cases
airlied: suokko: well that takes some sort of annotation
suokko: Something like lodclamp-between is impossible to pass
Ivanovic: agd5f: done
Ivanovic: thanks for your help
agd5f: Ivanovic: np
Ivanovic: now all i have to do is wait till this is fixed in mesa ;)
Ivanovic: btw great job on 3D support for r6xx hardware
FIReun: anyone been successful changing their mousepoll rate with recent xorg?
FIReun: suokko: yup
spstarr: wakes up
suokko: FIReun: So system adds lag to what you see
suokko: Idea here is that your input is signal that travels tough many places until you see action in screen
FIReun: suokko: I do a quick circle with the mouse and its lagging behind me a quarter to half a second
FIReun: suokko: but keyboard input is very responsive
FIReun: suokko: and it "appears" mouse input is going through same evdriver
suokko: Path is about kernel input driver->xserver->game->Do rendering with OGL->Graphics driver converts OGL to GPU language->push commands to GPU->do real rendering
suokko: So anyone of those steps can be queueing the signal too long and then you see lag
suokko: So first step is to make sure which one of those steps is real cause for lag
suokko: My suspect is radeon driver having too long queue. Specially for simple rendering
MostAwesomeDude: My guess is "push commands to GPU", i.e. DRI not working.
otaylor: FIReun: a lag of that much has nothing to do with mouse polling rates
otaylor: suokko: well, if keyboard input is responsive, that won't be it
suokko: MostAwesomeDude: FPS is high but latency is high too
FIReun: hmm
otaylor: FIReun: My guess would be that the game is getting flooded with mouse events in a way that the programmer didn't expect (different mouse behavior on windows, say), and it's doing some fairly large amount of work for every mouse event, and is getting way behind
FIReun: if I move the mouse slowly, it tracks, if I move the mouse the same amount of distance quickly, not only is there lag, but it overshoots
suokko: FIReun: Do you see different latency if you have more complex scene to render compare to simple scene?
FIReun: and maybe there is a small delay in keyboard input, but nothing like mouse lag
FIReun: suokko: no, fairly consistant
FIReun: suokko: and no video lag as if it cant keep up
suokko: FIReun: Then it looks like it some earlier step causing problems
FIReun: if i jerk the mouse quick, it spins my view quite quickly
otaylor: FIReun: what sort of game is this?
FIReun: usually in the past if I move quickly, even sound starts to drop out if things are overloaded
FIReun: otaylor: ioquake based
suokko: FIReun: Can you try latencytop then?
FIReun: I'll install it
spstarr: hmm
spstarr: looks at git commits
otaylor: Hmm, wouldn't expect bad problems with getting behind on moues events on something that is based on a well-known engine. Though it's possible the game is hooking directly into input rather than relying on the engine at a higher level
FIReun: suokko: i just suspect the mouse input level mostly because of the errors evdev spits all over the X log
spstarr: just MostAwesomeDude's r300g stuff in mesa git
FIReun: I dont trust it
suokko: MostAwesomeDude: Good example of latency is neverball and neverput ;) I can tricker it nicely there with hw cursor updated in real time but game menus with small delay
otaylor: FIReun:What's the scope of the bug? Just for you? Just for radeon drivers? For all linux users?
FIReun: otaylor: supposedly there is the game setting in_mouse which specifies where to get mouse events, but I've tried all the settings and seen no change
FIReun: otaylor: I've been trying to find others with the same problem
FIReun: otaylor: only old problems not on the current software setup, and their fixes do not change my problem behavior
otaylor: suokko: getting input latency right is hard - took me 15 years or so to really be satisfied that I knew how it should be done :-)
suokko: lgz
FIReun: latencytop - "Please enable the CONFIG_LATENCYTOP configuration in your kernel"
FIReun: meh
otaylor: FIReun: unless you have radically skipping sound and other huge problems all over the place on your system, I doubt it's anything to do with kernel latency
FIReun: otaylor: i agree
otaylor: FIReun: what latencytop is measuring how long the kernel gets uninterruptably busy (in my understanding), and if the kernel is getting uninterruptably busy for half a second...
otaylor: FIReun: if you move the mouse at just the right speed can you get the lag to become arbitrarily big?
FIReun: otaylor: the faster I move it the greater the lag
FIReun: "feels" like an acceleration issue
otaylor: FIReun: the longer the lag or the bigger the "gap"
otaylor: FIReun: if there's a constant lag time, then the faster you move the bigger the visual gap between your mouse cursor and something that is tracking it
FIReun: probably the latter then
otaylor: FIReun: Hmm, well, I'd try swapping out your mouse - it's a cheap experiment, especially if you can borrow one for the experiement :-), if that doesnt' help, then it really sounds like a game programming problem to me. Unless the lag for keyboard is the actually same and just isn't as obvious for one reason or the other. Then you might have a graphics driver problem.
FIReun: for every given unit of time, it seems to be a constant lag per unit distance... so the greater the distance moved in 1 unit of time, the greater the discrepency in position and the more noticable "catchup"
otaylor: FIReun: do sounds sync with the graphics or the moues?
FIReun: otaylor: if I reboot to ubuntu 8.10+fglrx, same hardware, there is no mouse lag
FIReun: otaylor: sound and video appear aprox synced
otaylor: FIReun: that doesn't actually prove anything - if firegl is just performing better (and it almost certainly is) that may hide the problem
FIReun: otaylor: this is qualitative, but my cpu fan screams while playing ioquake on fglrx, its only mid speed for radeon
spstarr: latency is a kernel's nightmare
FIReun: major improvement from the last time I tried the radeon driver
FIReun: I think when jaunty came out.
FIReun: otaylor: but I get the mouse lag even in the main menu, under little load
otaylor: FIReun: I could sit here and speculate all night, doubt I'd get to the root of the problem by guessing :-)
FIReun: otaylor: I just wish there were commands I could run to detect input stats
FIReun: then I could track it down as well
FIReun: again, my gut says its evdev
FIReun: I cant recall at the moment what command I ran, but the logitech mouse showed up as being handled by kbd
otaylor: FIReun: as I said, try swapping out your mouse then, because there's nothing about your evdev that's different than anybody elses other than the mouse
FIReun: I only have another logitech mouse to try
FIReun: s/mouse/trackball
otaylor: FIReun: well, I'm sure other people have logitech mice as well...
FIReun: http://pastebin.com/f6197acf
FIReun: my x log
FIReun: wtf is up with the macintosh mouse button crap? (accel)
FIReun: I appreciate any input from you all, this is just the last problem keeping me from making this radeon install of mine permanent and moving it local (from external drive) -- I dont expect you all to fix my problems when I demand it, but its nagging at me, and if you're curious or just have an idea about checking how I have something configured, I'd appreciate any input, but I dont expect it. (thanks in advance)
spstarr: FIReun: you are using KMS or UMS?
FIReun: KMS
spstarr: what GPU
FIReun: crappy rs480
spstarr: so that is using the r3xx-r5xx driver
FIReun: r300 I believe
FIReun: yes.
FIReun: there are plenty of these xpress200's out there no doubt.
FIReun: amd64
rmrfslash_: Hey guys. I want to move from the proprietary ATI driver *back* to the free driver to check it out. The only thing is that the last time I tried this it didn't work. What do I need to download and install for this to (hopefully) work? I have a ATI Radeon Mobility HD 3670
rmrfslash_: Didn't work meaning I never reached the GUI, just a command line. So I assume the driver didn't load
rmrfslash_: I'm running Kubuntu 9.10 (linux 2.6.31.*)
chithead: 2d/xv will work out of the box with latest ubuntu and fedora releases, for 3d a little extra effort is needed
rmrfslash_: is there a deb for ubuntu?
rmrfslash_: so I can be spoiled
chithead: if you want 3d acceleration, you need to use packages from xorg-edgers ppa
Nille02: in the ubuntu mainline ppa is an newer kernel but on this kernel KMS is not eoking for me
Nille02: rmrfslash_: lok at this https://launchpad.net/~xorg-edgers/+archive/ppa
Nille02: look*
rmrfslash_: So I need a newer kernel
rmrfslash_: This is a production system so I'm probably going to wait for 10.04 in April?
rmrfslash_: actually, that wasn't a question
Nille02: or use the ubuntu kernel http://kernel.ubuntu.com/~kernel-ppa/mainline/
chithead: if you are content with 2d and xv acceleration you can stay with what ubuntu 9.10 ships
rmrfslash_: I was there like a year ago (only 2D and XV accel)
rmrfslash_: I was seeing if 3D was working
rmrfslash_: and it looked like it was.
Nille02: yes with .32 and higher
rmrfslash_: and it seems to be working.... but w/ a newer kernel
chithead: it also works in fedora if you install one additional package
rmrfslash_: I'm thinking about switching to OpenSUSE
chithead: and it works in unstable releases of archlinux/gentoo/whatever distro is up to date regarding kernel, mesa, libdrm
rmrfslash_: the latest one w/ KDE 4.4
rmrfslash_: but I dunno
rmrfslash_: I'm kind of settling into ubuntu
rmrfslash_: I like some of the features
rmrfslash: I see
Nille02: or you can build your own kernel with make-kpkg its an oneliner
Nille02: Ivanovic: thx four you help with the firmware now its working
Nille02: mb but how can i view the radeon module options now?
FIReun: well I think I've resolved the biggest problem with the laggy mous
FIReun: I found a bit of help in a fedora doc in fact. the EVDEV in xorg 7.4 and the hotplug stuff it does means that you do NOT specify deviceinput blocks in your xorg.conf
FIReun: otherwise you run the risk of having your input events doubled, especially if you specify the mouse driver as "mouse" which uses the /dev/input/mouseX convention instead of the event* convention
FIReun: now, however, my fps seems to suck -- does not compute.
FIReun: like half what it was
FIReun: more testing!
bridgman: FIReun; what are you running to see half the frame rate ?
bridgman: IIRC interrupt support slowed down glxgears, but that was because of vsync not "slowness" (or something like that)
fireun: dunno, still backing out of my changes to see what caused it
fireun: I've put the entries back in my xorg.conf and its not behaving incorrectly again, really odd.
fireun: I think I'm gonna reboot, I chgrp/chmod the /dev/input/event* -- I cant see how that changed anything tho.
fireun: very strange.
fireun: brb
fireun: forgot to screen irssi
fireun: I just dont get it.
fireun: I've backed out all my changes, and the mouse still behaves (for the most part)
fireun: all the out of hand accelerated behavior is gone, in game gamma has dropped (no idea why) and fps is half what it was when the mouse was acting weird
fireun: is officially confused
airlied: dougmencken: pong if you are around
fireun: throws up his hands
fireun: I get a reasonable mouse, and lose the decent fps -- its just not fair
fireun: I was seeing a video bus showing up in the X log as an input device there for awhile
fireun: that was strange too
fireun: crazy hotplug
fireun: I should have kept a copy of that X log
fireun: oh wait, I do have a copy...
fireun: http://pastebin.com/f487a9c40
fireun: if anyone is idly interested
fireun: wait. where.
fireun: swears a bunch
fireun: wrong pastebin -- this is it -- http://pastebin.com/f40905b9d
fireun: "(II) config/udev: Adding input device "Video Bus" (/dev/input/event6)"
fisxoj: just to bring closure to my time here, I got KMS and DRI2 working, I built my own kernel and took out all the vesa/vga/efi framebuffer modules, don't know if it was that or the 2.6.33-rc7 kernel, but, both intel and radoen both work fine now
fireun: gotta love the "suddently and without any exact cause... everything works"
fireun: s/suddently/suddenly/
fireun: fisxoj: I seem to have fixed a 3dmode runaway mouse lag problem, while also somehow slowing my 3d fps
fireun: and its still darker than it was even adjusting in-game gamma way up
fisxoj: fireun, have you used it for wine games? I keep getting messages about "1x32 fp" and I was really hoping to play a game again
fireun: no I dont try wine
fisxoj: dang
BioTube: r600 build's broke
fireun: my video card sucks all by itself, all my experiences with wine are sub-par
BioTube: somebody used "DRM" for a constant that has "DRI"
fisxoj: hm... alt-tab switcher is quite slow
cxo: mesa debf00e5 (by Kristian) broke the build
BioTube: i mentioned that earlier(well, not the exact commit)
BioTube: "__DRM_TEXTURE_FORMAT_RGBA" should be "__DRI_TEXTURE_FORMAT_RGBA"
cxo: i hate people who are too lazy hit make before they commit stuff
MostAwesomeDude: I hate people that gripe without contributing.
airlied: or that are stupid
cxo: hates that too :)
BioTube: somebody even opened a bug
fisxoj: anyone else using radeon with wine?
cxo: I've played with wine a bit
BioTube: Half-Life with Steam just crashes
cxo: you can basically play any pre dx9 game
cxo: in other words anything before 2002 ish
fisxoj: and dx9c?
cxo: ?
MostAwesomeDude: I started working on TF2 for Gallium.
MostAwesomeDude: It starts, but dies while loading maps.
fisxoj: no support? some support?
MostAwesomeDude: Civ4 kills X for some reason.
spstarr: hmm
BioTube: wait - the half-life error is wine's fault
spstarr: BioTube: i haven't had issues building mesa but I did recently do a copy of libdrm drm headers clobbering /usr/include/drm ones
spuddweb: anybody got regnum online to work?
spstarr: man so many primitives in this scene, i dont think even the r8xx series could render all of this with more than 5fps even
spstarr: I hate games that do this :)
spstarr: granted, I cannot use all 512MB yet for txtures (as many in this scene are just not going to render)
spstarr: yet
spstarr: games keep pushing GPUs more :)
spstarr: hmm
spstarr: this post needs to be challenged on osnews
spstarr: "
spstarr: There are too many Linux-centric changes entering X.org, which is supposed to be a cross-platform graphics architecture. First, breaking it up into a bazillion packages, like a Linux distro, whereby any bit can be updated at any time. There's no real "X.org" releases, just distributions with almost random version numbers of packages. Then there was the inclusion of a dependency on HAL, even though every platform except Linux already had a (working|b
airlied: spstarr: not by anyone in here
airlied: stop pasting large chunks into the channel
spstarr: for one thing if he'd look at the code there's something called #ifdef :)
spstarr: not from anyone here, no
mishehu: bahs.
mishehu: ok, finally updating to kernel 2.6.32. I don't remember seeing anything in it about drm-next though
mishehu: were those patches from David Airlied merged into 2.6.32?
mancha: why not wait for 2.6.33 at this point?
mishehu: mancha: if that was the mentality I'd never upgrade anything hardware or software until smoke came out of it :-)
mishehu: plus I had to wait for another out-of-tree patch before I can update.
mancha: yeah but .33 is around the corner
mishehu: yeah well the patch I need *just* came out yesterday
mishehu: so I won't be able to up to .33 until that patch is available for it too
mekius: anyone going to commit a fix for the __DRM_TEXTURE_FORMAT_RGBA problem?