Home Phoronix Phoronix Forums X.Org Videos From FOSDEM 2008

Radeon IRC Logs For 2009-6-14

Search This Log:

DanaG: http://www.engadget.com/2009/06/11/new-amd-neo-athlon-turion-chips-emerge-in-hp-pavilion-dv2z
DanaG: wait, isn't that old news? =þ
nanonyme: Whoa?
DanaG: whoa what?
nanonyme: Three merges into r6xx-rewrite? :o
nanonyme: First radeon-rewrite, then mesa_7_5_branch, then master.
nanonyme: That was a lot of code merged in. :)
airlied: its just master merged in
nanonyme: Oh, right.
nanonyme: airlied: Those two merges other merges were in master's history then?
airlied: yes
nanonyme: Right.
nanonyme: hadn't noticed at all radeon-rewrite got merged into master; explains
nanonyme: It's still a lot of code though. :)
nanonyme: is happy it wasn't his job to solve the conflicts
bridgman: nanonyme; apparently the merge wasn't too bad, just a few files in drivers/dri/radeon AFAIK
nanonyme: Oh, nice. :)
bridgman: the code was already based on radeon-rewrite so all the hard work was done over the last couple of months
bridgman: this was just picking up recent changes
bridgman: now merging master into 6xx-7xx-support would have been "powerful ugly"
nanonyme: Hmm, that sounds like a very good reason for abandoning the r6xx-r7xx-support branch altogether. :)
mcgreg: aaaaargh
bridgman: yep, it's been lying on the side of the road for a while now
bridgman: it's a shame there's not a flag we can set ;)
bridgman: maybe a "best before" date or something
nanonyme: Do a commit that says "abandoned, do not use or change -> keep track on r6xx-rewrite"? ;)
nanonyme: It'll be eventually scrapped though, right?
bridgman: it is scrapped for all intents and purposes; Cooper used it to figure out one or two specific bugs while Richard was porting to 6xx-rewrite, but other than that 6xx-7xx-support was dead the day we opened 6xx-rewrite
nanonyme: Scrapped as in deleted with git. ;)
bridgman: the convention seems to be not to delete
nanonyme: >.<
bridgman: rationale being that the commit history may be useful even if the sum of the commits is not
nanonyme: Right. I guess you could push in a commit that prevents the r600 stuff from it from compiling as is and adding a note in commit message that you shouldn't use this branch.
nanonyme: s/adding/add in/
nanonyme: Should make the message clear. :p
nanonyme: (That is, some simple config failsafe)
bridgman: heck, we put in commits that stop things from compiling all the time...
bridgman: oh, you mean deliberately ;)
bridgman: yeah, probably a good idea... certainly easier than hunting down a bazillion old web pages
nanonyme: Preferably something that makes compile fail and output that you shouldn't be using this branch.
nanonyme: Erm, configure even.
nanonyme: You have to be pretty daft not to get the hint.
nanonyme: ;)
mimikry: bridgman: hi, are there at the moment people working on mesa R600 stuff?
nanonyme: Did you mean by that if they work on weekends or if they work at all? ;)
bridgman: mimikry; right at this moment, hard to say... I'm sure Richard is asleep but Cooper is in Shanghai so he might be working on it ;)
bridgman: but yeah, Richard is working on it full time, Alex and Cooper part time
mimikry: nice, nice :)
nanonyme: bridgman: Then again, he might be subconsciously producing new ideas for the code while asleep. Imo a bit funny that companies don't end up paying for that time too in innovative jobs. ;) You might end up actually doing it closer to 24/7 even if you just write code during paid time.
bridgman: we already pay for that, it's in the employment contract ;)
nanonyme: Heh.
bridgman: mimikry; here's the commit log... it's a bit hard to follow right now since we just resynced with master (so there are a ton of commits from master and radeon-rewrite as well) but it should settle down again and just have 6xx/7xx commits for a while
nanonyme: "Add RV740 support" is iirc the last commit before the merge.
bridgman: probably the easiest is to go into the tree, navigate down to src/mesa/src/drivers/dri and then click on "log" beside the r600 folder
bridgman: http://cgit.freedesktop.org/mesa/mesa/log/src/mesa/drivers/dri/r600?h=r6xx-rewrite
nanonyme: I've been trying to keep a track on the log because I'm hunting for a "enable clear code" commit. ;)
nanonyme: Or implement, whichever. :)
bridgman: I think we know what's wrong now anyways
bridgman: probably get fixed next week
nanonyme: Right, no rush. At least I won't have to go compile after every commit now that I know what I should be waiting for.
bridgman: yeah, just look for that "holy &^%$^ it works !!" commit
nanonyme: :D
nanonyme: bridgman: I'm also kinda interested as to whether the code would make the actual rectangle draw properly. :) (it's distinguishable atm but draws wrong)
nanonyme: Guess we'll see.
bridgman: it should... as I understand it we get passed vertex information in a number of buffers - one for position info, one for colours, one for textures... like basic GL vertex arrays
bridgman: except we don't actually get passed colour info under certain conditions
nanonyme: Oh.
bridgman: it's not clear whether this is a recent optimization in mesa or has always been the case
DanaG: oh yeah, I'm going to be trying out compiz+kms on karmic on an R100 soon, I think.
bridgman: DanaG; make a video
DanaG: Radeon 7500, specifically.
DanaG: Sure. How should I record it?
DanaG: I've noticed some video recording apps -- and even gnome-screenshot -- can get screwed up under compiz.
DanaG: Or was that just nvidia that did that? =þ
DanaG: Last time I screenshotted compiz was with the nvidia.
bridgman: I was sort of kidding; I was thinking you could play it back at 4x speed or something ;)
DanaG: I'm also curious which is a bigger factor in compiz dropping to 30FPS (from 60) if I enable always-transparent cube, on my R600... more likely a driver issue, or a memory bandwidth issue?
bridgman: I remember how slow Compiz was on my thinkpad with M9
DanaG: Hmm, CPU will be an Athlon XP (Barton) ~2GHz.
DanaG: I'm also curious what I'd be able to get a Voodoo3 to do -- besides being blurry, thanks to low-quality analog output -- given the same CPU.
bridgman: are there working drivers for Voodoo3 ?
DanaG: I know for sure I'll be able to get a desktop; anything beyond that, beats me.
DanaG: I do remember comparing my voodoo3 to a geforce2 (on WinXP), and noticing the voodoo2 being better in at least one respect: it can do video overlay at 1280x960; the nvidia couldn't.
bridgman: ok, so worst case shadowfb+gallium3d softpipe ;)
DanaG: I know there are Glide drivers of some sort.
nanonyme: How old is Voodoo3, btw?
DanaG: eh, 1999-2000-ish.
nanonyme: So maybe between two to three machine generations old depending on the way you count, I guess. :)
bridgman: rage 128 era
bridgman: or early radeon I guess
p4ddY`: FallenWizard? even with kdemod-testing desktop effects don't work
osiris_: airlied: this long comment in r300RenderPrimitive doesn't apply anymore, right?
airlied: don't think it makes sense any more.
airlied: my only worry would be a flush due to aperture space maybe.
airlied: &
nanonyme: Hrm.
Jake1: can someone help me w my radean mobillity 1300 for F11?
adamk_: Just ask your question :-) If someone can help, they will.
Jake1: i have no 3d support
Jake1: EE) RADEON(0): [drm] Could not create vertex/indirect buffers list
adamk_: Use a service like http://pastebin.com/ to show us your full /var/log/Xorg.0.log file.
Jake1: http://pastebin.com/m40cc1e5e
adamk_: Hmmm... I think you're going to need someone with more knowledge than me...
adamk_: I think he's away at the moment, but I'd keep an eye open for airlied and see if he has any ideas.
Jake1: ok thanks
TCW: fjakwhat distro?
TCW: Jake1, even
nanonyme: TCW: Fedora 11 as he said.
Jake1: haha Fedora 11
TCW: oops, sorry :)
TCW: Jake1, was fglrx installed before?
Jake1: before waht?
TCW: Jake1, before you did tryout the foss driver
Jake1: ok
TCW: ok?
nanonyme: Jake1: Was that an answer to the question? :)
Jake1: what is the foss driver?
nanonyme: Just means the opensource driver.
TCW: Jake1, Free and Open Source Software... the one you are using right now
Jake1: ohhh ok i upgraded from F10 i was having problems w/ my card in F10 as well
nanonyme: Yeah but have you had fglrx installed at any point?
nanonyme: As in, the ATi closed driver.
Jake1: yes i had that in F10
Jake1: the proprietary driver one
nanonyme: Right.
TCW: Jake1, how did you unisnatll it? Did you uninstall it?
nanonyme: It sometimes uninstalls uncleanly so you might have to reinstall Mesa.
TCW: uninstall even
Jake1: ok
nanonyme: TCW: It's not supported yet in Fedora 11.
TCW: nanonyme, what?
nanonyme: TCW: fglrx
TCW: O_o?
nanonyme: Kernel version issue.
nanonyme: Iirc.
nanonyme: Catalyst won't run on 2.6.29 without hacks.
TCW: Ahh... F11 ships without fglrx right now?
Jake1: yeah
nanonyme: Yes. Though Fedora has never officially shipped fglrx.
nanonyme: It's part of an external package repository rpmfusion.
TCW: Whatever... nice to hear anyway ;)
nanonyme: Fedora is free. ;)
TCW: Jake1, anyway, as nanonyme has said already, re-install all packages considering dri and mesa
nanonyme: (So free that it doesn't even include mp3 support by default)
Jake1: lol
Jake1: ohhh ok
TCW: Jake1, and make sure you have a perfect sane upgraded system and not a mixture
Jake1: ok how do i do that?
TCW: I don't use fedore, you do, you should know :)
nanonyme: I just left for parents' so I don't have a Fedora at hand anymore. I'd ask on #fedora on how to make sure you've gotten rid of the closed ATi display drivers.
Jake1: ok
adamk_: Jake1, It can't hurt to reinstall the following packages: mesa-dri-drivers, mesa-libGL, and xorg-x11-server-Xorg
Jake1: ok
adamk_: Jake1, Also, just in case, what's the output of 'lsmod | grep fglrx' and 'dmesg | grep drm' ?
nanonyme: adamk_: It's 2.6.29+Fedora patches so it shouldn't be able to load fglrx. :)
nanonyme: (In case he managed to upgrade properly to F11)
Jake1: root@localhost Jacob]# lsmod | grep fglrx
Jake1: [root@localhost Jacob]# dmesg | grep drm
Jake1: [drm] Initialized drm 1.1.0 20060810
Jake1: [drm] Detected VRAM RAM=65536K, accessible=65536K, BAR=262144K
Jake1: fbcon: radeondrmfb (fb0) is primary device
Jake1: fb0: radeondrmfb frame buffer device
Jake1: [drm] Loading R500 Microcode
Jake1: [drm] Num pipes: 1
Jake1: [drm] writeback test succeeded in 1 usecs
Jake1: [drm] Initialized radeon 1.30.0 20080528 for 0000:01:00.0 on minor 0
Jake1: shoot i tried to put that into an Fpaste but aparently i didn't
adamk_: That's alright... I think we can forgive you this time.
adamk_: Unfortunately, that all looks perfectly normal to me.
Jake1: i know and thats why this is so confusing haha
adamk_: If reinstalling those packages doesn't help, you could try booting with the 'nomodeset' kernel option to see if it makes a difference.
amarsh04: back in a few, testing grub2
nanonyme: Ergh.
nanonyme: Grub2? o.O
stikonas: Grub2 works fine for me
nanonyme: Yeah but afaik it's not used by default in stock Fedora.
Jake1: ok they are all remove now i reinstall them?
nanonyme: What exactly did you remove?
Jake1: all 3 of them
nanonyme: If you want help, don't be so obscure.
Jake1: haha sorry
Jake1: mesa-dri-drivers, mesa-libGL, and xorg-x11-server-Xorg
adamk_: Jake1, Yes, reinstall them.
Jake1: ok and restart?
adamk_: Hmm... It can't hurt to unload and reload the kernel module, so rebooting may be a good idea.
Jake1: brb
kernelpanic: Since upgrading to kde 4.2, using newest radeon/mesa from yesterday's git, X crashes when I start console or right-click on the plasma panel. I get backtraces like http://nopaste.org/p/aqbhklhdB. It's a radeon rv530. Could someone please give me a hint?
Jake1: hello room i tried reinstalling mesa-dri and the xorg however in fedora 11 i still have no 3d support
vdv: hi all
vdv: http://lists.opensuse.org/radeonhd/2009-01/msg00126.html
osiris_: glisse: I tried implementing texture tiling, but I've hit a major problem. the current cs manager doesn't allow for writing relocs with mask i.e. we have TX_OFFSET_n regs where offset takes only 5-31 bits, and lower bits are used for setting tiling and endian swap
osiris_: glisse: is there an easy way to hack around it?
PuffTheMagic: does anyone know what branch of mesa I need to get dri with kms
glisse: osiris_: newttm kernel side does support that
stikonas: PuffTheMagic: master branch
glisse: osiris_: are you talking about cs from libdrm ?
osiris_: no, the one included with mesa
glisse: oh when in dri1 mode ?
PuffTheMagic: i have mesa from git/maser
PuffTheMagic: but i get this:
PuffTheMagic: (EE) RADEON(0): [dri] RADEONDRIGetVersion failed because of a version mismatch.
PuffTheMagic: [dri] radeon.o kernel module version is 2.0.0 but version 1.17.0 or newer is needed.
PuffTheMagic: [dri] Disabling DRI.
joss: glisse, newttm branch where can i get information about that, there was an intel branch also?
glisse: joss: it will hit linus soon
glisse: otherwise that branch :
glisse: http://cgit.freedesktop.org/~glisse/drm-next/log/?h=radeon-dave
joss: glisse, you mean for radeon only, i've seen that in git, but memory manager part wasn't there when i fetched last:)?
PuffTheMagic: glisse: is there a better way to make sure fbcon is up before radeon than this patch here: http://git.zen-sources.org/?p=zen.git;a=commitdiff;h=093f1cb1a1850951f86244ada018672885ec4ace
PuffTheMagic: it fixes my blackscreen/hardlock
PuffTheMagic: with everything built into kernel
PuffTheMagic: but i doubt its the best fix
glisse: dunno i neeed to look into that
joss: glisse, ok, seems it has i915 parts also, but newttm memory manager is only in radeon i assume right?
glisse: joss: yeah intel wont get ttm and doesnt need it
nanonyme: Yeah, would be quite a surprise if they didn't use GEM. :p
nanonyme: Considering they designed it, after all. :)
joss: nanonyme, haven't seen a stable UXA/dri2 yet, sure it exists somewhere with gem also though
nanonyme: joss: As far as I've heard, Intel couldn't manage to make a stable EXA either. *shrug*
joss: glisse, so radeon doesn't have really this composite problem, stacking of composited gl windows?
glisse: joss: don't see what you are talking about
joss: nanonyme, that's false exa is stable with the above mentioned error
nanonyme: joss: Well, they *did* drop it and after I queried on whether it made sense, I got a bit fiery comments from Intel users that it's good that the buggy code got stripped out. ;)
joss: glisse, when your compositing with XComposite you can't redirect windows that have gl context as simple as that
glisse: joss: it does work with dri2 on intel or radeon at least if i understand what you are taking about
mjg59: nanonyme: I think the point was more that EXA was always going to be more performance constrained than UXA in a unified memory environment
mjg59: And required a silly number of hacks to attempt to cope with that
joss: glisse, yes, forces uxa understandebly with intel, cause exa lacks the hack, unstable totally i would say currently
joss: uxa, ok got it, radeon has only exa accelerator?
nanonyme: Correct.
nanonyme: Though I'd be very interested if someone explained to me exactly how 2D accel works with Gallium. :p
bridgman: for simple stuff there are a couple of useful calls in Gallium like CopySurface (going from memory here)
bridgman: there are some nuances I'm not sure about, ie whether the xorg state tracker points to a slightly different winsys which uses the privileged x server calls into drm
bridgman: but in terms of drawing stuff, 6xx/7xx EXA and XV accel are using the 3D engine anyways
bridgman: I think EXA uses a couple of specialized blend modes which may or may not be exposed through Gallium3D
nanonyme: Right.
bridgman: and I don't think we use the depth buffer, but otherwise anything you can do with directly programming the 3d engine should be doable by setting up and running the shaders through G3D instead
nanonyme: So it is a completely separate thing and Intel might end up dropping UXA too in favour of Gallium3D's 2D accel? :)
bridgman: UXA vs EXA is more related to buffer management etc... my guess is that UXA would stay and just go through Gallium3D to get to the drawing hardware
nanonyme: Ah, right.
bridgman: fyi here's the EXA code from the xorg state tracker :
bridgman: http://cgit.freedesktop.org/mesa/mesa/tree/src/gallium/state_trackers/xorg/xorg_exa.c
nanonyme: Not very complete yet, it seems. :) Does describe the interface though.
nanonyme: Or hmm. Actually compositing handling seems to be the stuff that's not implemented yet.
bridgman: should be just a matter of drawing to an offscreen buffer AFAIK
bridgman: Gallium3D isn't picky
joss: nanonyme, not sure about buffer management, i have tested only one chip 945gme, compositing gl -- damaging the whole screen with dri2 is CRAP, not sure wether it's the case with 965:)!
nanonyme: joss: Using their newest development code? (then again, I don't use that, I wouldn't know of regressions either)
joss: nanonyme, yeah, but never heard from google that a stable version of UXA is there, but none really post the results of compositing either, damage etc.
nanonyme: I can just say that I was under the impression Intel drivers were quite far. No personal test results and I'm open to accept the fact that I was wrong. :)
joss: nanonyme, i don't think gallium has interface for 2d's compositing even if they have an engine for 2d operations
bridgman: compositing is normally done with the shaders anyways
bridgman: 3d engine, point the texture engine to input buffer, and draw a quad
nanonyme: bridgman: There's functions ExaComposite, ExaPrepareComposite and ExaCheckComposite which always return FALSE.
joss: bridgman, hmm, then sounds good, can you make a window transparent that way?
nanonyme: That's what I meant.
nanonyme: Implies it is designed to do something when using compositing. :)
joss: nanonyme, they won't meet with 3d without dri2 , though i must see those particular functions, i tried with xrender
nanonyme: joss: As bridgman linked http://cgit.freedesktop.org/mesa/mesa/tree/src/gallium/state_trackers/xorg/xorg_exa.c
nanonyme: Then ExaWaitMarker and ExaMarkSync also need to be implemented, I have no idea what they are for though.
joss: nanonyme, ah nice, missed that link
PuffTheMagic: [dri] radeon.o kernel module version is 2.0.0 but version 1.17.0 or newer is needed.
PuffTheMagic: ^^^ what do i need to d to fix this?
PuffTheMagic: it does not even make sense
PuffTheMagic: 2.0.0 is newer than 1.17.0
nanonyme: It does if you do comparison incorrectly.
nanonyme: As in 17 > 0.
nanonyme: Though I don't know if it's the case.
nanonyme: PuffTheMagic: Are you using development versions of anything?
mjg59: More likely that 2 and 1 have different ABIs?
mjg59: If so, it's unclear
PuffTheMagic: i have glisses ttm/radeon kms patches in my kernel, and I have git mesa and git xorg-server
PuffTheMagic: along with the needed git libs
PuffTheMagic: like libdrm
PuffTheMagic: etc.
nanonyme: And libdrm is of the right branch?
PuffTheMagic: i thought I asked which is the right branch for that and I though someone said master
PuffTheMagic: but i guess thats not right if u are asking
PuffTheMagic: which repo should I be using for libdrm?
nanonyme: It didn't use to be a while ago, unsure if that's changed.
nanonyme: Wait a bit.
nanonyme: glisse's guide seems to mention modesetting-gem.
PuffTheMagic: nanonyme: the guide that came out a few months ago?
nanonyme: Yeah.
PuffTheMagic: hmm k i can try that
nanonyme: I can't notice a merge in master's history anyway.
joss: nanonyme, there is dri2 xorg tracker too, don't know alanh and brianp usually produce working code, maybe that's the way to go:)
joss: chromium seemed to work reliably
stikonas: nanonyme: http://cgit.freedesktop.org/mesa/mesa/commit/?id=7f223ff89172069dbad987f592aea2a8ba16355f
nanonyme: stikonas: That's Mesa, not drm.
nanonyme: We were talking of drm branch.
nanonyme: I do know radeon-rewrite merged into master in Mesa. :)
PuffTheMagic: right
stikonas: they will probably merge drm when KMS ABI is stable
PuffTheMagic: but im sure there are other bits in non master repos
PuffTheMagic: libdrm is probably one of them
nanonyme: Make sure? :)
joss: nanonyme, but yeah, from there it's seen that dri2 and exa may meet somewhere
nanonyme: Iirc X driver also meant to have a specific branch.
nanonyme: Checking.
PuffTheMagic: nanonyme: yeah it needed one at somepoint
PuffTheMagic: i really havent played with kms since october
MostAwesomeDude: joss: DRI2 and EXA are not related at all.
MostAwesomeDude: TTM and Radeon KMS are already submitted for 2.6.31; it's up to Linus to merge them.
nanonyme: MostAwesomeDude: Thumbs up? :)
bridgman: I don't think Linus is looking at MostAwesomeDude's thumb for this ;)
PuffTheMagic: MostAwesomeDude: why dont tih us in zen any more?
PuffTheMagic: wow
PuffTheMagic: bad lag
PuffTheMagic: s/tih/hang with/
joss: MostAwesomeDude, xorg_tracker.h defines exa and drm comm, i only seen earlier prototypes of exa-ttm , they must be related to do compositing. maybe not:) i dunno
bridgman: so going back to EXA composite; AFAIK Exa Composite is different from Composite - EXA composite is more or less XRender support, while the COmposite extension is the ability to redirect drawing to an offscreen buffer
bridgman: the composite extension makes compositing possible, and EXA composite might be used by the compositor, but AFAIK that's about it
MostAwesomeDude: joss: No connection at all. The xorg state tracker exposes EXA by using Gallium calls.
bridgman: and both names are really a bit misleading
MostAwesomeDude: bridgman: Yeah, you've got it exactly.
nanonyme: bridgman: Mostly meant that could hope we're lucky and he doesn't have a bad day at the point when he's looking into merging the stuff... :3
mjg59: Linus ought to defer to others on this point
joss: bridgman, yeah but using that buffer with current alorithms for 3d for instance parallel rendering, Xcomposite seems poor
mjg59: As long as stuff's submitted before the merge window closes, he'll tend to trust subtree maintainers
nanonyme: Right.
MostAwesomeDude: mjg59: There have been discussions on this before. I think that he'll accept it.
mjg59: Also, Linus runs on intel
bridgman: so as long as the changes don`t break intel we`re OK
bridgman: that last character was supposed to be a question mark
joss: :) bridgman heh nice, then linus won't scream, THIS whole merge series has been full of people sending me untested crap!
bridgman: joss, have you read cworth`s recent blog post about performance in UXA
mjg59: bridgman: It's more that changes that /do/ break Intel tend to get a lot more attention than the others
bridgman: so using Linus for regression testing on intel is not a good strategy
nanonyme: :D
nanonyme: cairo-perf-trace? I guess I should look into that. (reading cworth's blog)
joss: bridgman, not yet, i must be moving on , my BIG picture of open source graphics may be fuzzy, cause i fetch too slowly here, sure there is a hacked working prototype but i haven't met one, since i own a laptop a first time dunno how other chips work
joss: via is possibility to switch to, but i wan't to make couple of changes dunno, wether those are possible with via and nvidia
joss: bridgman, as for intel it's promising and eeepc seems good, if there is an accelerator that won't degrade 3d perfromance and does an alpha blend transparency it will do
bridgman: all the modern chips will do blending; the challenge with performance is that you either need a decently fast GPU or you need a highly tuned graphics stack
bridgman: and the tuning is just beginning
nanonyme: joss: Btw, http://cworth.org/intel/driver_stability/ :)
bridgman: nanonyme; I was thinking of a more recent post
richtroye: Hi, Compiz worked fine with Fedora 10, fails with Fedora 11, on my laptop, Xorg log is pastie.org/511681
bridgman: http://cworth.org/intel/performance_measurement/
richtroye: The compiz-check program said that "Software rasterization in use" was why my compiz fails.
bridgman: richtroye; that seems to match your X log; the ddx driver is coming up ok but there`s a warning about direct rendering being disabled
bridgman: can you pastebin dmesg output
richtroye: bridgman yup, one moment
bridgman: looks like the ddx driver is not able to open drm
bridgman: are you running the drivers that installed automatically with F11
bridgman: is a question mark by the way ;)
richtroye: bridgman pastie number 511694 is the output from dmesg
bridgman: and are you specifying -nomodeset when you boot
MostAwesomeDude: Looks like F11 kernel buggies.
bridgman: ok, here`s the problem
bridgman: [drm:drm_agp_bind_ttm] *ERROR* AGP Bind memory failed
bridgman: [drm:drm_ttm_bind] *ERROR* Couldn't bind backend.
bridgman: [drm:drm_buffer_object_validate] *ERROR* Failed moving buffer. dac65600 256 2000031 10000a0
bridgman: [drm:radeon_alloc_gart_objects] *ERROR* failed to allocate ring - most likely an AGP driver bug
bridgman: doesn`t mean I know how to fix it tho ;(
MostAwesomeDude: richtroye: Boot with "nomodeset" on your kernel command line.
bridgman: MostAwesomeDude; that`s the odd thing... looks like user modesetting is running, but the ttm messages in kernel make me think kernel modesetting is running to
bridgman: like it`s the wrong radeon driver version or something
richtroye: ok, will do, MostAwesomeDude -- thanks
bridgman: radeon from master rather than the kms-friendly version from F11
MostAwesomeDude: bridgman: Well, I bet that disabling the KMS will make it take the safe, older init path.
bridgman: yep, sounds good
MostAwesomeDude: If this does work, he'll need to file a bug.
bridgman: assuming he is running the drivers that F11 installed and not something else
richtroye: for sure, it's a virgin F11
osiris_: glisse: would it be hard to backport it to non kms?
richtroye: MostAwesomeDude with kernel parameter nomodeset, my compiz-check no longer shows the "Software rasterization in use" error
MostAwesomeDude: richtroye: Great. And compiz works?
MostAwesomeDude: richtroye: You should file a bug against Fedora.
richtroye: MostAwesomeDude Perhaps it doesn't. I went to system -> preferences -> desktop effects and clicked the bar, and it logged me off! After auto login, I was back to my non-compiz operation.
MostAwesomeDude: Hm.
richtroye: Trying that procedure again I got this time a "do you want to keep this setting" box and said yes, and then it logged me off again as before; again after autologin i was out of special effects.
richtroye: Want more pastes?
bridgman: it`s an IGP part with RN50 core; my guess is that it`s really a bug
richtroye: Lots of messages glxinfoL2439 freeing invalid memtype
richtroye: glxinfo 2439 freeing invalid memtype, I mean
joss: nanonyme, not sure what card cworth is talking about, most things seem to be true though. used the same repo 945gme got a fix there with 30kernel and 2.6.xx performing better then earlier drivers without memory manager, as for uxa and that intagrated chip i don't know yet
joss: nanonyme, seems uxa is fixed for 965 at this time, not sure
nanonyme: joss: He's talking about intel development in general.
nanonyme: Not just some card.
bridgman: yeah, the main point was that there`s some progress on modelling performance in a way that lets the devs do something about it
nanonyme: I also saw that one of the major messages was that he called end-users to participate in the development process and give more feedback so developers can better make drivers for them that work.
nanonyme: They do want to know.
glisse: osiris_: thing is tiling is a bit special in dri1 case iirc
osiris_: why?
Wizzup: bridgman: Are you busy? I've been messing with the radeon driver a bit more (not the hd one), and when I start it, it doesn't error. But it simply gives a black screen
nanonyme: bridgman: Yeah, this was a different issue I was talking about. Sorry, reading backlog the wrong way. :)
nanonyme: As in, apparently Intel is in a situation where end-users try out the development results with considerable lag which makes quality assurance a lot harder. There's only so many things you think of testing.
bridgman: you could still move the mouse pointer as well, right
glisse: osiris_: need to check but part of it is handled in the kernel
glisse: long time i haven't looked at that on dri1
nanonyme: I've noticed radeon developers seem to have taken quite an active stance and advertised improvements that need testing which helps in the matter a lot. :)
dileX: glisse: for-glisse-only branch to work properly with r500 and dri-initialization requires (again) to revert "drm: don't associate _DRM_DRIVER maps with a master". otherwise known errors like formerly I had
MostAwesomeDude: dileX: I'm not too sure, but I don't think that that branch is meant for public consumption. :3
nanonyme: (Since an improvement which doesn't get testing might well degrade quality of the product)
richtroye: MostAwesomeDude My dmesg pastie for those two failures & relogins is 511721
bridgman: I figured that `for-glisse-only`had to be a clue ;)
dileX: MostAwesomeDude: yupp, I know.
nanonyme: dileX: Sounds like an experimental branch which is supposed to be broken half of the time to me. ;)
glisse: dileX: where is for glisse-only ?
dileX: nanonyme: its good with the revert (even with 2.6.30-git7 on top)
_Groo_: hi/2 all
nanonyme: dileX: Yeah but who's to say the commit didn't break stuff on purpose. :)
nanonyme: (Except glisse, of course)
glisse: dileX: use the radeon-dave branch in my repo
glisse: or just wait things get merged and we delete all various branch to work on top of linus tree
osiris_: bridgman: did you find anything new about this ALT_NUM_VERTICES reg?
richtroye: MostAwesomeDude Any thoughts on my symptom? I'm trying also to find where that glxinfo message comes from, could it be driver mtd/nand/nand.ko or nand_ids.ko ?
MostAwesomeDude: richtroye: You never showed me a glxinfo message, and it has nothing to do with those drivers.
richtroye: oh ok, it was in the latest pastie, 511721, there were scads of them
richtroye: MostAwesomeDude I'd failed to tag your nick onto the lines above that I'd mentioned glxinfo in, sorry
MostAwesomeDude: Oh, I see. Those would be an indication that something's going wiggy in TTM-land.
richtroye: It's all new to me. ttm-land?
richtroye: there I go again failing to tag. :-( MostAwesomeDude It's all new to me. ttm-land?
nanonyme: The moving of memory management to kernel.
dileX: glisse: I see. is there any (positive) feedback to TTM and radeon-kms patches? acceptance?
MostAwesomeDude: glisse: http://pastie.org/511721 richtroye's dmesg; lots of compiz fail
richtroye: afk for a couple of mins
joss: MostAwesomeDude, so have you bencharked a 3d status of radeon open source, wine opengl games. ogl scenegraphs etc.?
joss: *mark
glisse: MostAwesomeDude: this is ati agp chipset issue
glisse: well not really an issue
MostAwesomeDude: joss: Nope.
MostAwesomeDude: glisse: Is an AGP quirk needed?
glisse: for what ?
MostAwesomeDude: To make his stuff work.
joss: MostAwesomeDude, someone should do that, intel seems ok mostly, then status of radeon would be clear also
MostAwesomeDude: joss: Status: Stuff works.
joss: MostAwesomeDude, ok, good then..run aa just in case afterwards to confirm:)
richtroye: MostAwesomeDude i'm back
glisse: richtroye: open bug attach xorg, kernel message, lspci ...
glisse: i will look at that latter got to go
richtroye: glisse ok, xorg, dmesg, lspci, to what bug-url?
MostAwesomeDude: richtroye: bugs.freedesktop.org
richtroye: thanks
richtroye: i mean thanks MostAwesomeDude :-)
MostAwesomeDude: NP
richtroye: MostAwesomeDude should I worry about security windows from firefox for that site? "Add Security Exception" window. Happy to continue. url https://bugs.freedesktop.org/
MostAwesomeDude: richtroye: Nah, it's fine.
richtroye: k
joss: MostAwesomeDude, one question to go, do you happen to know accidentaly wether wayland can work with dri1 too?
MostAwesomeDude: joss: No idea.
stikonas: joss: I think no, iw was designed to use Gallium and KMS
stikonas: and Gallium3d comes with DRI2
richtroye: MostAwesomeDude On the bugs.freedesktop page among the 'product' listings I don't see radeon nor compiz, which should I pick?
MostAwesomeDude: richtroye: drivers/dri/r100 or drm
richtroye: MostAwesomeDude neither is a choice. how about 'DRI' ?
MostAwesomeDude: DRI works.
richtroye: ok will do
richtroye: MostAwesomeDude None of the 'version' items except 'unspecified' seems to be right. the only xorg one is "XOrg 6.7.0"
joss: stikonas, ok, saw a working kms too with my chip, no dri2 yet though
stikonas: joss: have you compiled all needed userspace components?
joss: stikonas, heh wrong channel i use intel at the moment, don't know if wayland works with radeon at all
MostAwesomeDude: richtroye: Do "unspecified" for now.
richtroye: MostAwesomeDude ok will do. Is there a way to add more than one attachment to a bug report before hitting the "Commit" button?
MostAwesomeDude: richtroye: Nah, gotta add 'em separately.
richtroye: yikes ok
richtroye: MostAwesomeDude okay, bug 22284
richtroye: Let me know if there's something you'd like that I didn't provide, please
MostAwesomeDude: richtroye: It's not for me, it's for glisse. :3
nanonyme: Iirc Wayland has inbuilt compositing so probably no point even thinking of it before getting fast OpenGL and DRI2. :)
nanonyme: Kinda like you'd have Compiz that you can't get rid of. :p
PuffTheMagic: what is the right branch for ati driver to use with kms?
nanonyme: Hmm, the X driver?
PuffTheMagic: yeah, seems like the one in master is the only one thats been worked on in a while
PuffTheMagic: err radeon-gem-cs3 in glisse's repo is only 10days old
PuffTheMagic: maybe its that one
nanonyme: hopes the age of crapload of branches will start reaching its end finally ^^
PuffTheMagic: yeah me too
nanonyme: With good luck at least one thing won't branch again when all distros migrate into KMS+mm world. :P
nanonyme: As in, if people move to xf86-video-modeset MostAwesomeDude mentioned. :) Assuming it's simple enough, it probably doesn't take that many rewrites to get it to reach its final state...
PuffTheMagic: yes hours ago
PuffTheMagic: oops
PuffTheMagic: wrong window
joss: /join #intel-gfx
nanonyme: :p
joss: nanonyme, i haven't tried vnc spu with dri1, wonder if one could make vmware transparent with transset with dri1 for instance, don't have dri2 at all, wonder how it's gonna look if two opengl windows moving content are clipped and both transparent 20%:)?
osiris_: nha: have you ever seen cubemap test passing on r300?
nha: osiris_: r300 seems to have odd trouble with cubemap mipmaps
nha: osiris_: i.e. the miplevel calculations seem to be slightly incorrect
nha: osiris_: that's why I added the cubemap-relaxed test
joss: nanonyme, imho dri1 , composite and exa have to meet, this all to work out, seemed pretty easy when i first looked at it, but xgetwinattribute is expensive and blocking as they say.. what's the function to hammer with then?
osiris_: nha: there's no such test, didn't you mean crash-cubemap-order?
nha: osiris_: there should be such a test in piglit's r300.tests
nha: unless it got deleted at some point
nha: hmm you're right, apparently it got deleted at some point
nanonyme: joss: Sorry, I'm probably the wrong person to talk to regarding designing new technology especially at 23:33.
joss: nanonyme, going to sleep as well myself tomorrow vnc spu as last shot spawn all opengl windows as vncviewer ones..see what that meks until uxa is stable
osiris_: nha: on my rv535 there're only 9 failing tests: fdo20701,r300-readcache, exactRGBA, makeCurrent, polygonOffset, vertProg1, cubemap, gen-compressed-teximage and tex3d
nanonyme: *shrug* I wouldn't know anything of how well UXA works, I only have ATi cards.
osiris_: I've found the problem with tex3d, so it should be 8 soon
joss: nanonyme, that's the same, dri1 and dri2 then, never mind dri2 performance is slow here dri2==UXA on intel
nha: osiris_: r300-readcache should also be quite easy to fix, but the fix is quite quirky; you need to read from some random, different location on video memory before reading from video memory, to clean some hidden cache somewhere
nanonyme: joss: I also can't use DRI2 because it's not supported on any of my ATi cads.
nha: vertProg1 might fail simply due to the LIT corner case
nha: compressed textures are a bigger thing
joss: nanonyme, ah ok:)
nha: exactRGBA - tbh, that part of the OpenGL spec is just completely braindead in my opinion; there is no way you can reasonably implement that part of the required functionality without creating some pretty damn illogical code
nha: also, I would be really surprised if people relied on the behaviour exactRGBA expects, because you would naturally expect different behaviour
osiris_: nha: in vertProg1 there're 12 failing tests. it's possible that one of my latest patches broke it, because I don't have earlier results on rv535
nha: ah okay
osiris_: fdo20701 is fbo related so it's a false negative
osiris_: Dave is fighting with makeCurrent
osiris_: looks like there isn't that much to fix
airlied: osiris_: for tiling I was intedneing on relocating the tiling bits in the kernel
airlied: I'll redo color buffer tiling on top of glisse work once its in Linus
airlied: as it slightly changes ABI
osiris_: cool
AndrewR: hi all. Welcome back, Dave!
osiris_: airlied: I've found what's the problem with small 3D textures
joss: nanonyme, night, then you should also have a problem wm not knowing how to stack composited opengl windows, even fullscreen opengl screesaver is messed, it's only with compositor enabled though:)
osiris_: airlied: in radeon_teximage we call texImage->TexFormat->StoreImage to copy data from user
nha: I read there is some debate on merging shader stuff into gallium or not?
osiris_: airlied: this function doesn't seem to preserve dstRowStride if it's bigger than actual
airlied: nha: I think its just MostAwesomeDude not wanting to read code ;-)
osiris_: airlied: I have one solution for this, but it isn't optimal
airlied: he thinkgs your shader optimiser is too complex for him to understand :-P
airlied: osiris_: StoreImage are mesa functions aren't they.
osiris_: yes
nha: I see
osiris_: but I really don't know why would these functions fail for 3D textures only
joss: airlied, you know if on a longer run i915 driver will gain shaders or not?
nha: well maybe I can help out there, but I'm going to be travelling quite a bit these next months, so who knows...
airlied: joss: it has shaders, I doubt it'll get GLSL though.
joss: ok
joss: they fall to software heavily here, night
airlied: osiris_: where should it be storing that value or using it?
airlied: it looks like it should be using it properly
PuffTheMagic: nanonyme: yup, radeon-gem-cs3 is the xorg driver branch to use with kms :D
osiris_: airlied: yeah, but I had to do one more copy with copy_rows function to align rowstride to 32 bytes to make it work
airlied: osiris_: can you show be the patch you are using? just so I get an idea (still early in the morning :-)
osiris_: airlied: that patch was ugly, so I prepared little more invasive one. one moment
nanonyme: More invasive? ^^
osiris_: it changes the way that texture data are handled
osiris_: airlied: http://pastebin.com/m28566576
PuffTheMagic: can someone explain to me why every laptop I have had makes funny sounds once 3d is enabled
PuffTheMagic: sounds like mice inside the computer
osiris_: with this patch the StoreImage function stores data in some temp memory, and the data get copied with proper rowstride to mt during buffer validation
airlied: where do we free the temp?
osiris_: currently nowhere :P it's WIP
airlied: sounds like the miptree might justneed fixing
osiris_: why?
airlied: either adding another param to hold rowstride
airlied: or storeimage needs fixing
airlied: I can't see why storing to the miptrwee is breaking it
nha: PuffTheMagic: higher power consumption might lead to some not-so-high-quality-condensators making noise? or maybe some other effect where things start vibrating due to some oscillating currents, and the change in power consumption changes the characteristics, and that causes the funny sounds
osiris_: airlied: are all relocs aligned to 32bytes?
airlied: which bit of the reloc?
airlied: the buffers are all 4k aligned
osiris_: airlied: e.g. tex offsets
airlied: I think the miptree code aligns the offssets
rehabdoll: a general question: how does radeon handle the fan-speeds on newer cards, say a 4890? is it just full throttle all the time?
_Groo_: rehabdoll: dri1 ou kms/dri2?
_Groo_: rehabdoll: for what i know, radeon as rudimentary powermanagement for dri1, dri2/kms i believe isnt ported yet
rehabdoll: ok, thanks
nanonyme: rehabdoll: I'd guess your BIOS defaults are used.
osiris_: airlied: I've found the problem. here's the patch http://pastebin.com/mb9e9833
osiris_: it also removes unused code and fixes some indentation
airlied: osiris_: it seems to remove some compressed texture code
airlied: can you just put the bug fix in on its own first?
osiris_: airlied: sure
MostAwesomeDude: Dang it, nha came and went.
ajax: MostAwesomeDude: so, tell me about shatter.
MostAwesomeDude: ajax: So all TTM/GEM drivers do DRIVER_HANDLES_PIXMAPS, right?
ajax: i think that's true now, yes.
MostAwesomeDude: And AFAICT all of them can do scanout from anywhere in VRAM.
ajax: there are cards where that's not true but nothing modern.
MostAwesomeDude: So, CreatePixmap and DestroyPixmap should be sufficient for allocating root shards.
MostAwesomeDude: I think we still need a major bump, because EXA needs to be able to ask the DDX to set the CRTCs up with certain pixmaps.
Xeccos: trying to get X to start on secondary graphics card, /var/log/Xorg.0.log http://dpaste.com/55419/
ajax: sure
ajax: i'm really not concerned with how many apis need major breaks. i was assuming at least one would.
airlied: break em all
MostAwesomeDude: Breaking EXA gives me the power to clean out all the classic EXA code. Of course, it has the unfortunate side effect of all the pre-Big Three cards not working, but eh.
Xeccos: card is Mobilitiy 3650 on a laptop, any help would be appreciated
ajax: MostAwesomeDude: whatever's easiest to implement, really. cleanup is mechanical, i'm looking for "works at all" here
MostAwesomeDude: ajax: Same here. :3
airlied: ajax: so what happened the old shatter idea? (too complex or just plain impossible?)
ajax: airlied: doing it at the GC level? mostly just too complex.
Xeccos: big issue seems to be "(--) PCI: (0@2:0:0) ATI Technologies Inc Mobilitiy Radeon HD 3650 rev 0, Mem @ 0xc0000000/536870912, 0xfddf0000/65536, I/O @ 0x0000c000/256, BIOS @ 0x????????/131072" and therefore "(EE) RADEON(0): Cannot read V_BIOS (3) Input/output error"
ajax: i was definitely trying too hard in trying to write it so it could be reused at the xinerama level too
MostAwesomeDude: It makes a lot more sense in EXA, since it leans so heavily on kernel MM.
Wizzup: Xeccos: Have you gotten radeon to work on the Mobility 3650? (with X)
Wizzup: I kind of wonder because I haven't succeeded yet
Xeccos: i have not
Wizzup: What distro do you use?
Xeccos: gentoo
Wizzup: Heh. Same
[Enrico]: gentooer are common here :D
Wizzup: What kernel?
Xeccos: i've gotten radeon to work on the other card in my laptop, a 3200, but i'd like to get the 3650 to work as well
[Enrico]: is using gentoo too :D
Xeccos: linux-2.6.29-gentoo-r5
[Enrico]: Xeccos: for a radeon hd 3650 i suggest you to use the .30 kernel
Wizzup: http://xorg.freedesktop.org/wiki/radeon%3Ar6xx_r7xx_branch
[Enrico]: it has drm support for it. mine don't works with .29 but with .30 it works with EXA and xv enabled (btw you need lastest testing libdrm and xf86-video-ati)
Xeccos: i keep upgrading as they get listed as stable
Wizzup: Add it to package.keywords
[Enrico]: Wizzup: with .30 kernel you don't need do follow that wiki anymore
Wizzup: [Enrico]: I linked him nevertheless, it would save some explanations
Xeccos: i'm not sure i like the idea of running a testing version of the kernel..
[Enrico]: oh true :D
Wizzup: Xeccos: http://wizzup.pastebin.com/d154c8a03 That's what I have in package.keywords
[Enrico]: Xeccos: testing for gentoo, the kernel itself is stable
Xeccos: oh ok
Wizzup: [Enrico]: What X version do you use?
[Enrico]: Wizzup: the stable one 1.5.3-r6
[Enrico]: for xorg-xserver i mean
[Enrico]: xorg-server*
Wizzup: I was thinking of trying 1.6, as I am still on the black screen issue
[Enrico]: Wizzup: i don't think it is related but....... well i have 1.6 on another system with a radeon 9250 (r200) and it works pretty well, but i doubt it will solve your problem
[Enrico]: Wizzup: sound like some mess around
Wizzup: What?
[Enrico]: Wizzup: did you checked the ~/.xsession-errors ?
Wizzup: doesn't exist
[Enrico]: Wizzup: really really strange
[Enrico]: Wizzup: you xorg.0.log doesn't contain errors and no error is reported, just a black screen......... there is something messed up
Wizzup: Yes
[Enrico]: Wizzup: may be there is a missing deps....... well you can try to install gnome to see (you use gnome if i remeber well)
Wizzup: Hmm, I could... I don't think it would matter though
Wizzup: I may have found a solution so I can use radeonhd...
[Enrico]: Wizzup: likely
[Enrico]: Wizzup: radeonhd? mhm i feel better with radeon....... it is less experimental
[Enrico]: and most complete :D
Wizzup: well, I compiled the xorg-server with support for both, so I'm just messing around with both
[Enrico]: Wizzup: well you can also try to add the ModeLines to your xorg.conf. i can show you mine example (but it will not work on your pc)
Wizzup: That is indeed one thing I haven't tried yet
[Enrico]: Wizzup: this is my xorg.conf (it is a mess i know but it works) just ignore the fglrx part (i need fglrx for 3d atm) http://pastebin.ca/1460518
[Enrico]: Wizzup: and be aware DON'T USE MY MODLINES!
[Enrico]: Wizzup: they will not work on your monitor
Wizzup: I won't
[Enrico]: since we have different definitions
[Enrico]: well i go to sleep now
[Enrico]: nn all :D
Wizzup: Hmm.. sleep
Wizzup: Night
Xeccos: night
Wizzup: sleeps
[Enrico]: :D
Wizzup: Xeccos I hope you'll have more luck than I've had to far
Wizzup: so far* :)
Xeccos: thx
jon5001: is fglrx better in jaunty than intrepid?
MostAwesomeDude: No clue.
spstarr: is a Fedora person, whats this Jaunty and Intrepid thing? ;)
airlied: and whats this fglrx thing, read topic
jon5001: i meant, is the open source driver better. sorry. i have radeon x300
airlied: ah newer usually is better
MostAwesomeDude: Yeah, for your card, fglrx is no longer the recommended driver.
DanaG: s/the recommended driver/an option/