Curan: Reading the DriHistory I came across the links to PI's homepage which don't work anymore, could anybody with write access in the wiki maybe add links to archive.org where those pages are still available?
Curan: like http://web.archive.org/web/20020202133413/http://www.precisioninsight.com/dr/dr.html for the http://www.precisioninsight.com/dr/dr.htm link
Curan: (I don't have an account in the wiki and it seems a little bit too much too me to create one for just adding two links)
vehemens_: r7xx is getting closer, got a glxgear without a kernel panic!
EruditeHermit: vehemens_: just one?
vehemens_: better then last night
DanaG: is that like "a scissor"?
EruditeHermit: vehemens_: is that one gear spinning repeatedly or one frame of the gears?
vehemens_: one frame of gears. i think it hung on a lock at that point. don't have the latest mesa changes however (last 24hrs).
vehemens_: using a hd 4650 (rv730) right now. got a couple on sale to replace my dead cards.
EruditeHermit: airlied: hi, did the debugging info I gave you earlier help?
EruditeHermit: airlied: or should I try something else?
EruditeHermit: airlied: and if you still have a link to that page, I'd appreciate it because I could post it in the bug report
nanonyme: agd5f: Hmm, is there a listing of all EXA hooks so I might disable them for testing? Apparently NoAccel also disables DRI which causes OpenGL not to work and RenderAccel false doesn't appear to do anything...
nanonyme: Apparently EXA is causing interference, imo it'd be interesting to see just how far it ranges.
nanonyme: Right, I've actually been here once already.
nanonyme: Found from the logs.
mcgreg: I've got a laptio with a mobility 4650 and the radeon driver cannot find any screen...
mcgreg: should it work "normally" / is it supported?
chithead: it should be supported as long as the driver is sufficiently new. pastebin Xorg.0.log
mcgreg: it is ... 6.12.2
mcgreg: the current one from debian usntable
nanonyme: wonders what technically would happen if OpenGL and EXA tried to use the same areas in VRAM.
mcgreg: I could try fglrx ... but I'D rather use radeon ... any ideas?
jcristau: mcgreg: commit 68001981f22173ff949720055dba89291f284474 added your pci id
mcgreg: so I need to get the current radeon git?
nanonyme: Lol. :D
jcristau: master or 6.12-branch would work
nanonyme: Only now found --disable-exa in configure. :) This'll be simple.
mcgreg: hmmm I have the 6.12 one installed... but I'll try fetching master git
jcristau: you said you had 6.12.2 installed. there are newer commits than that in the 6.12 branch
mcgreg: oh sry then, I misunderstoof
nanonyme: Does it make any sense that OpenGL stops working altogether with --disable-exa?
nanonyme: Makes one think there might be plenty other state setup missing too.
nanonyme: (which r600 Mesa driver would be relying on for ddx EXA to set)
mcgreg: was the command this one : ./autogen.sh --prefix=/usr/ (correct?)
mcgreg: it works :D very good. thanks you very much jcristau :)
mcgreg: cool. now I have a laptop (asus) with amd cpu, amd gpu and amd southbridge :)
mcgreg: power managmnent seems to works good as well :)
mcgreg: wlan0 is detected properly... this is why I love linux so much :)
Weiss: nanonyme: in my understanding of at least the Intel driver, EXA is used to make all pixmaps be backed by GEM objects (i.e. VRAM/GART space/whatever), which means that DRI2 can come along later and use them for rendering "fun stuff"
Weiss: i don't know if DRI2 can work without EXA, given that, but maybe there's an alternative route
Weiss: Mesa and EXA shouldn't end up using the same memory areas, because either: with DRI2, there is a unified memory manager; or with DRI1 they have completely separate pools
nanonyme: Weiss: Well, my point was mostly whether or not r600 driver (and in time r600g) should be able to run without EXA existing.
Weiss: my understanding is that that doesn't work in the current architecture, but i'm ready (willing, even) to be shown i'm wrong
nanonyme: Since currently it obviously cannot and is pretty badly interfered by EXA usage.
nanonyme: Like, say, it lockups when you use Xv or start Firefox.
Weiss: how are you disabling EXA for your tests?
nanonyme: (which is as far as I've understood due to missing state setup still; I was mostly wondering how far do you have to actually go to setup the states)
nanonyme: I couldn't find the EXA hooks in the manual so it's a bit hard to figure out exactly what to disable so I just did --disable-exa in configure.
nanonyme: I was planning to disable hooks one by one originally.
Weiss: take a look at radeon_dri2_create_buffers() in radeon_dri2.c: to get the GEM handle for a pixmap (which ends up in Mesa), it does exaGetPixmapDriverPrivate(pixmap)->bo
nanonyme: Hmm, right.
Weiss: DRI1+no EXA should work though.. (?)
nanonyme: It doesn't.
Weiss: that's what you're testing?
nanonyme: And there's no DRI2 for r600 yet.
Weiss: ah, ok
Weiss: ignore most of what i just said, in that case
nanonyme: Technically all of this probably is irrelevant since you're very unlikely to have r600 running without EXA.
nanonyme: Weiss: But yeah, separate memory pools it is then. That's comforting. :)
Weiss: that's only my understanding. i haven't really been studying DRI1
nanonyme: And really, it might be that --disable-exa drops off more functionality than I bargained for anyway. Would need to read through what code actually is left out if USE_EXA isn't defined.
MrCooper: nanonyme: it probably means no acceleration at all basically; also lockups are an issue of the driver, not EXA
nanonyme: MrCooper: They are, yes. It's just that running programs that use EXA/Xv influences behaviour in r600 driver.
nanonyme: (which is also a bug in the r600 driver)
MrCooper: programs don't use EXA directly, they just talk the X11 protocol to the X server
nanonyme: Thanks for the clarification though I don't see how it changes anything.
MrCooper: basically I'm not sure why you're wondering about the drivers working without EXA in the future, as that's not directly relevant for the problems you're referring to
nanonyme: Yes, that's very likely a waste of my time.
nanonyme: That is, finding out whether it does or not.
MostAwesomeDude: Hm. EXA just uses a few hooks to do things, and it's pretty airtight from what I've seen.
MostAwesomeDude: If you're getting rendering errors or lockups, it's DDX, not EXA.
nanonyme: MostAwesomeDude: Actually the idea I've heard is that r600 isn't setting states correctly yet and there's no problem with ddx or EXA.
nanonyme: I was still playing along with that.
MrCooper: if by 'r600' you mean the Mesa driver, that isn't involved with Firefox or Xv unless you're running OpenGL apps at the same time
nanonyme: MrCooper: This was a strictly OpenGL application related lockup.
nanonyme: Triggered by EXA/Xv.
MostAwesomeDude: nanonyme: So the EXA/Xv 3D engine reinit isn't properly setting something?
MrCooper: or the same thing in the 3D driver
nanonyme: MostAwesomeDude: Hmm, I got the impression it was the other way around as in the 3D driver wasn't properly setting something.
nanonyme: And that was actually why I was interested that since EXA/Xv interferes with OpenGL rendering, what would happen if I disabled EXA altogether.
nanonyme: Result was no OpenGL.
nanonyme: (but unreliable results, as I said, since I haven't yet checked if it disabled more than I bargained for)
kdekorte: MrCooper, we were talking to agd5f last night about it. Basically he put out a patch that fixed glxgears on r600 by setting the FS state
kdekorte: When he did that however, locking up the display was quite easy
MrCooper: most likely that just means there's more state management issues in one or both drivers
nanonyme: kdekorte: Did you move any windows or do anything that might have been EXA accelerated just before the lockup?
kdekorte: He decided to set the FS state cause glxgears would color properly on r6xx chips when you ran mplayer -vo xv or moved a window around really fast in EXA mode
kdekorte: yes, I activated a gnome-terminal window and tried to type in it
nanonyme: Well, simply activating windows wasn't enough to do it for me.
nanonyme: Had to start something.
nanonyme: (well, I was mostly trying with Firefox)
kdekorte: Locked up quite quickly for me, in fact I was the one that first noticed the lockup.. I commented out the code agd5f added and the lockups went away, but glxgears then displayed bad again
kdekorte: I was wondering if the fact that the ddx and mesa were both talking to the 3d engine was a problem. maybe some queuing needs to be done or something
kdekorte: Maybe the chip does it, so it is not a problem
MrCooper: kdekorte: it should be handled via the DRM, though of course there may again be driver bugs in the code related to that
kdekorte: for me when it locked up Xorg was using 100% cpu and even killing Xorg didn't bring the display backup. So agd5f, thought it might be a chip lockup
kdekorte: I'm on kernel 2.6.29 (Fedora 11) in 64bit mode
nanonyme: Hmm, Nils was right.
nanonyme: Setting GLX_STENCIL_SIZE to 1 fixes glxgears.
nanonyme: That is, the black screen problem.
nanonyme: Which is a tad puzzling.
kdekorte: nanonyme, maybe agd5f, needs to reset the stencil as well as the FS
kdekorte: with that stencil set to 1, are you using git head and firefox works without lockups?
nanonyme: No no, this is regarding the fullscreen black screen.
nanonyme: I haven't tried anything else yet.
nanonyme: The fullscreen black screen disappears with stencil set.
kdekorte: how do you set the value?
nanonyme: He makes glxgears set it.
kdekorte: Ah, I see.. I thought it was an environment setting
nanonyme: Apparently size of the stencil buffer in bits.
nanonyme: Errr, one bit buffer? :)
MrCooper: the minimum size
nanonyme: Does it essentially make it not buffer or what?
MrCooper: it'll only match GLX visuals with at least 1 stencil bit
MrCooper: are you sure it isn't falling back to software rendering?
nanonyme: No. Actually it apparently did it *again*. (and apparently my monitor just went on pwoersave as well for a few seconds spontaneously)
nanonyme: Seems it drops to software rasterizer for no seemingly good reason every now and then.
nanonyme: Wait, no. I'm just being stupid.
nanonyme: MrCooper: You're absolutely right.
nanonyme: (But it still did help for the program though now that I actually got to use r600 again)
nanonyme: But yeah, probably no point thinking too much of it, iirc agd5f had an idea of what might have caused it and it's reproducible.
nanonyme: (even if it's not for him)
agd5f: nanonyme: you can "disable" EXA by returning false in all the driver hooks. there's no option to disable it at the moment. However, the 3d driver is probably missing some state setup which is what is causing the problems
nanonyme: agd5f: Yeah, I was hoping to find the names for the hooks in some documentation. Couldn't find it in man radeon.
nanonyme: Obviously blindly returning false for all EXA functions didn't work. :3 (yes, I apparently always try the stupid stuff first when I can't find documentation)
nanonyme: Hmm, DFS, UTS probably at least.
bridgman: actually I thought blindly returning false probably *was* the right idea
nanonyme: bridgman: X server didn't even start when I tried that. ;)
bridgman: in cases where there is a prep function that precedes the actual processing you probably just need to return false in the prep function
bridgman: there's probably one that you shouldn't disable ;)
agd5f: nanonyme: R600PrepareSolid(), R600PrepareCopy(), R600PrepareComposite()
agd5f: and comment out info->accel_state->exa->UploadToScreen = R600UploadToScreen;
agd5f: info->accel_state->exa->DownloadFromScreen = R600DownloadFromScreen;
agd5f: or just return false in solid and copy and set EXANoDownloadFromScreen, EXANoUploadToScreen, and EXANoComposite in you config
nanonyme: Right, restarting X to find out.
nanonyme: Hmm, it didn't start.
bridgman: ok, back out the changes and make it work again
agd5f: it works fine here, just sw rendering
nanonyme: Right, back in X after git reset --hard.
nanonyme: kicks his X.org stack
bridgman: agd5f; must make 3D seem pretty fast ;)
nanonyme: Slightly ironic having just listened for a dozen minutes to a BSD developer claiming X.org components don't get enough testing in a youtube video. ;)
agd5f: nanonyme: http://www.botchco.com/alex/xorg/r67_no_exa.diff
nanonyme: (And yes, I suspect my stack is probably patched till death anyway... :3)
nanonyme: (ignoring the tons of errors caused by the interference between the object between the monitor and the chair and my X.org components)
nanonyme: Trying that now.
nanonyme: As this one seems to have been too.
nanonyme: Finding the lockup could be a simple matter of turning stuff on incrementally and seeing what triggers it, right?
agd5f: nanonyme: not really. most of the 3d state is shared by all of exa and XV
nanonyme: Bah, right. :)
agd5f: it's probably some state that the the ddx sets, but the 3d driver doesn't
kdekorte: agd5f, is it possible that the 3d driver and EXA are stomping on each other?
agd5f: kdekorte: shouldn't be
nanonyme: Right. I guess I'll "just wait and shut up or read the damn source" then. ^^
agd5f: other than the missing state
kdekorte: agd5f, could it be the stencil that is missing?
nanonyme: The fullscreen black screen appears to be completely irrelated to this EXA/Xv stuff though.
agd5f: kdekorte: have to look though all the regs set by the ddx and all the regs set by the 3d driver and see what's not set on the 3d site
agd5f: it could also just be bugs in the 3d driver
nanonyme: (considering it still happens with those modifications)
kdekorte: but I thought you didn't write buggy code... ;)
bridgman: nanonyme; *what* still happens with the modifications ?
bridgman: black screen, or occasional corruption in the drawing ?
nanonyme: Black screen.
bridgman: makes sense; any change in the corruption ?
nanonyme: I don't think I got corruption or lockups without EXA hooks.
nanonyme: bridgman: Did you see that thing Nils noticed and commented on in the glxgears thread?
bridgman: yes and no; I saw it, but I haven't looked through it in detail
bridgman: it's unlikely the stencil buffer itself is the issue, but it's possible we program something else at the same time as the stencil buffer, so seems like a useful clue
agd5f: see if my latest commit helps
agd5f: there were 3 regs weren't emitting in the 3d driver
agd5f: that we were in the ddx
nanonyme: Right, compiling.
nanonyme: Corruption's still there.
bridgman: agd5f; maybe a dumb question but the commit you posted didn't seem to actually write anything into those registers, just added the infrastructure to write to them if you chose...
bridgman: or is there some kind of "initialize the driver copy of all registers to zero" loop I missed ?
bridgman: nanonyme; still getting black screen ?
agd5f: bridgman: the struct gets allocated as zeros
MostAwesomeDude: bridgman: Not sure exactly what LINK_STATES expands to, but most structs in Mesa are calloc'd.
nanonyme: bridgman: Yeah.
bridgman: ok, now there's also some code which actually writes the driver copy of the registers out to the ring, grouped into chunks of state
bridgman: is there also something I missed that actually writes these new values out to the chip ?
bridgman: (this is how I learn ;)
agd5f: bridgman: LINK_STATES is a linked list that we walk and emit
agd5f: so every reg in that list gets emitted. the others are emitted in separate functions
agd5f: e.g, the clipping and db regs
bridgman: ok, so routines like r700SendSQConfig aren't the only way those values get emitted...
bridgman: I thought the lists of registers seemed a bit short ;)
agd5f: r700SendContextStates() walks the list
bridgman: reminds himself that reading the beginning and end of a source file does not necessarily give you the whole story ;)
kdekorte: agd5f, the latest git, gives some interesting results
kdekorte: but basically still locks up X
koolfy: I'll never get tired of reading all that
koolfy: I hope one day I can understand it all and contribute :p
bridgman: I keep noticing that the corruption mostly appears on the red gear, which is what gets drawn first
kdekorte: on r600 I don't see any gears, just a lot of pixels
nanonyme: bridgman: Btw, I'm not getting corruption in the actual gears but only outside the window.
bridgman: ok, that's useful; agd5f, is current thinking still that corruption outside the window is most likely to be memcpy ?
bridgman: nanonyme, did you ever get corruption in the actual gears, eg occasionally red gear is drawn smaller or seems to break up into a bunch of triangles ?
kdekorte: I've seen it breakup into a bunch of triangles for a split second
nanonyme: I don't think I did.
kdekorte: I rebuilt mesa and now gears is working better
bridgman: yeah, that's the corruption which we think might be related to state information
nanonyme: Oh, right.
kdekorte: I do see the smaller red gears flash every now and then
kdekorte: ok, while gears is running if I drag a window around, I get corruption below the gl window
nanonyme: kdekorte: Yeah, bridgman just talked of that.
kdekorte: looks like the Y part of the memcpy is copying to much
kdekorte: only appears below
bridgman: I also noticed that if you drag another window so that it obscures (say) the lower left quarter of the gears window then the bottom half of the gears window stops being updated
kdekorte: if I drag a terminal window over the gl window, X locks up hard
bridgman: so definitely something funny in the clipping code for memcpy
nanonyme: You have different behaviour with it then. ;)
bridgman: didn't see lockup (other than running "trim"); kdekorte, which GPU ?
kdekorte: I can move the mouse around (it is corrupted)
kdekorte: bridgeman r635
bridgman: ok, should be similar to my rv620 then
bridgman: don't think I've tried dragging a terminal window, will test when I get back to my pc
bridgman: which means signing off from here, bbl
kdekorte: using gnome/metacity
bridgman: huh; metacity like the compositor ?
kdekorte: no composite enabled
kdekorte: metacity like the window manager
kdekorte: with mesa git on r635, several of the redbook demos look better... (teapots for example)
bridgman: good; teapots was looking pretty ratty when I last tried it a few days ago :)
kdekorte: movelights even looks better
kdekorte: demos/bounce finally looks good... yea!
nanonyme: Apparently teapots works now for me too, didn't work some time ago.
kdekorte: demos/geartrain has some artifacts, but much better than before
nanonyme: The top-right-most gear?
kdekorte: demos/gamma still has placement issue with the first square
kdekorte: nanonyme, yes the one in the back on the right... some white near the bottom of the gear
kdekorte: demos/cubemap, locks X hard
kdekorte: so mouse, no nothing
kdekorte: is there any reason to even mess with the memcpy and just dump it and work on the preferred way to move content to the card
nanonyme: kdekorte: The preferred way is not done yet? :)
nanonyme: Or rather, the code to use it isn't.
soreau: So I'm on Jaunty, using the stock 2.6.28-11-generic kernel. What would I have to do in order to get dri2 working here? I already have the latest xf86-video-ati from git working
bridgman: soreau; which GPU ?
soreau: bridgman: Radeon 9600
nanonyme: Installing 2.6.31 with KMS support on in staging sounds like a good idea to do it. ;)
bridgman: I think you just need 2.6.31 kernel and latest mesa from master
nanonyme: Yeah and libdrm from master with --enable-radeon-experimental-api.
soreau: Maybe I better try breaking my gentoo install instead :)
bridgman: there are some special build instructions still, I think
bridgman: like nanonyme just said ;)
soreau: bridgman: Link?
bridgman: just the --enable-radeon-experimental-api think AFAIK
boghog: thinking of giving this stuff a try as well - also on gentoo
soreau: for both the driver and mesa? or libdrm too or?
chithead: soreau: for libdrm and mesa there exist ready-made live ebuilds in the x11 overlay. no need to break anything
boghog: soreau, if you choose to break gentoo: there's an x11 overlay with the latest stuff (I think they're git ebuilds)
nanonyme: soreau: Just libdrm.
soreau: chithead: I have to unmask them, presumably (?)
chithead: soreau: yes
soreau: nanonyme: ok
soreau: Thanks chithead, boghog
yangman: soreau: http://airlied.livejournal.com/66958.html
nanonyme: soreau: ddx from master, nothing special, Mesa from master, nothing special, libdrm from master, --enable-radeon-experimental-api, kernel 2.6.31 with staging kernel modesetting for radeon
boghog: copy pastes
nanonyme: yangman: Looks out of date.
nanonyme: (or then I'm badly mistaken)
yangman: nanonyme: why would it be out of date?
soreau: yangman: Awesome, thanks
nanonyme: yangman: I was under the impression you'd no longer need the kms-support of ddx.
yangman: oh. probably
yangman: ah, yeah, it's merged to master now
soreau: yangman: So what would be different with respects to that information?
yangman: soreau: radeon from master
soreau: yangman: So just git the driver, no special branch?
soreau: gotcha, thanks
boghog: hrm did I check out xf86-video-ati at a bad time? getting some compile errors: http://pastebin.com/m3bb9b888
boghog: libdrm should have been compiled with --enable-radeon-experimental-api
boghog: unless gentoo's x11 overlay ebuild is doing things I don't understand :p
agd5f: boghog: replace all the DRI2BufferPtr with DRI2Buffer2Ptr in radeon_dri2.c
boghog: argh, wgetpaste is broken
boghog: ah dpaste.com is down
boghog: think this will be fixed in git soonish? i fear that by the time I figure out how to add a patch to a gentoo git ebuild there won't be a need for it anymore :p
nanonyme: agd5f: What's the common protocol of trying to get a patch to get accepted for the driver, some mailing list or what?
agd5f: nanonyme: send to the appropriate mailing list
boghog: ah, EGIT_PATCHES to the rescue
boghog: seems to be reverting to swrast because: dlopen of /usr/lib64/dri/r600_dri.so failed (/usr/lib64/dri/r600_dri.so: cannot open shared object file: No such file or directory)
boghog: is there sometihng I need to --enable when building mesa for r7xx ?
chithead: boghog: you need the r6xx-rewrite branch
boghog: is there an easy way to get the mesa git ebuild to use that branch?
chithead: note that r6xx/r7xx 3d is not yet useful for anything but simple opengl demos
chithead: boghog: yes, read the ebuild
boghog: i know, just wanted to give it a try and see what happened
boghog: hmm, can't find anything in the ebuild about it, but I'll look at git.eclass
boghog: ah got it, EGIT_BRANCH
boghog: meh, that fails with http://pastebin.com/mc54aed4
boghog: disables egl for now
ahmed-araby: Hi all I'm using radeon driver , can it be the cause that my Linux box freeze some-times ?
ahmed-araby: The mouse move very slowly & every thing stop working !
Nille02: 3d testing stuff ?
Nille02: ahmed-araby ??
ahmed-araby: Nille02, no
EruditeHermit: ahmed-araby: what card??
Nille02: if yes I have the same issue
Nille02: hd 3850
ahmed-araby: EruditeHermit, Ati radeon HD
EruditeHermit: ahmed-araby: check the bugs on bugs.freedesktop.org
EruditeHermit: you might want to file a report
EruditeHermit: can you reproduce the crash at all?
EruditeHermit: or is it random?
Nille02: what's the problem ? because its sounds like my problem ^^
ahmed-araby: really It hard to know , most of times when using firefox
ahmed-araby: sometimes when just opening any player
ahmed-araby: but it happens with firefox alot
ahmed-araby: Some times with specific web sites , I tried to use any other browser but still freeze at particular pages
biotube: those pages wouldn't happen to use Flash, would they?
boghog: hrm, giving mesa --disable-egl and removing it from --with-state-trackers, still makes it try (and fail) to compile egl, anyone know what else I could try to get around http://pastebin.com/mc54aed4 ?
ahmed-araby: I use flash block addon
ahmed-araby: so simply no flash is running untill I click it
ahmed-araby: but youtube works fine
rnoland: agd5f: am i seeing that right... you merged into master?
boghog: ah, looks like fix was committed
agd5f: rnoland: yes
rnoland: agd5f: so is dev moving to master, or are you just checkpointing?
agd5f: rnoland: dev is moving to master
Nille02: agd5f: with you drm and the current mesa ( r6xx-rewrite ) my xserver freeze :(
rnoland: agd5f: awesome...
agd5f: rnoland: it shares much of the common code with radeon/r200/r300
agd5f: so easier to keep in sync on master
rnoland: agd5f: good deal.
agd5f: Nille02: what kernel are you using?
Nille02: ubuntu jaunty
Nille02: for 2 days its works "fine"
agd5f: Nille02: does it freeze when you start a gl app or when you start X?
Nille02: gl app
EruditeHermit: ahmed-araby: can you try with firefox 3.0?
EruditeHermit: ahmed-araby: is it with firefox 3.5 that they crash?
ahmed-araby: EruditeHermit, I've already tried many browsers like opera
ahmed-araby: Same thing
ahmed-araby: http://fpaste.org/paste/19076 , this is xorg log
EruditeHermit: ahmed-araby: see if you can follow the instructions of post #4 in this bug report
boghog: oh hmm, fix was only committed to master but not 6xx-rewrite
EruditeHermit: boghog: 6xx rewrite is merged to master now
kdekorte: Nille02, when was the last time you updated the code? Freezes were common with the code from last night
kdekorte: so if I am testing the r6xx code , I should switch to master?
Nille02: kdekorte: 40 - 50 min
agd5f: kdekorte: yes development has moved to master
kdekorte: Nille02, might try doing a make clean and reinstalling
kdekorte: agd5f, ok, switching my scripts to use that
Nille02: I try it brb
boghog: cool, well it compiles and loads now, except running glxgears makes my screen flash (i can see a window for a fraction of a second) and then prints: IRQ's not enabled, falling back to busy waits: 2 16\n drmRadeonCmdBuffer: -22
kdekorte: ok, got 32bit and 64bit mesa code working... gears runs ok
kdekorte: I tried etracer about an hour ago... figured it would not work... hard locked the video card with a black screen... oh well
agd5f: boghog: sounds like you need a newer drm
rnoland: r200_cmdbuf.c:109: warning: no previous prototype for 'r200EmitScissor'
rnoland: r200_cmdbuf.c:239:32: error: macro "radeon_bo_open" requires 7 arguments, but only 6 given
rnoland: r200_cmdbuf.c: In function 'r200AllocEltsOpenEnded':
rnoland: r200_cmdbuf.c:237: error: 'radeon_bo_open' undeclared (first use in this function)
boghog: mm, I think I'm using git master - but I'll doublecheck
kdekorte: boghog, you should be using the r600-r700-support branch, unles that just changed
kdekorte: sorry r6xx-r7xx-3d branch
chithead: libdrm master should have all the required things now
soreau: chithead: and fwiw, xf96-video-ati-9999 pulls in xorg-server-9999 anyway
soreau: xf86 ;)
boghog: i don't see that branch on freedesktop.org git
chithead: iirc that branch existed only in agd5f's repository
agd5f: for libdrm master is fine, but for the kernel modules, you need my repo
boghog: ah ok
kdekorte: boghog, read http://www.botchco.com/agd5f/
boghog: was using those from 2.6.31-rc3
boghog: i hate it how i take the time to learn some basic git (checking out switching branches) usage and then next week I've forgotten all of it
kdekorte: boghog, I do the same thing
boghog: i think ill make a little note this time :p
boghog: ah: http://ktown.kde.org/~zrusin/git/git-cheat-sheet-medium.png
Nille02: kdekorte: ? I have now reinstalled mesa from master an I have the same issue. the system freeze an the mice is very slow
kdekorte: what desktop are you using KDE or gnome?
kdekorte: You might try switching to mesa - master branch and repulling and rebuilding
Nille02: and yesterday morning ist works
Nille02: I have do this
Nille02: im now on master
kdekorte: ok that is good
Nille02: exa and xv works
kdekorte: if you just run gears and don't touch anything else does it crash right away?
Nille02: brb I try some mesa demos and not glxgears mybe I have an other resoult
nanonyme: Hmm, r6xx-rewrite merged to master? That's be a pleasant suprise. :)
rnoland: i'm getting a build error from r200 on master right now...
soreau: rnoland: The same one you posted ^^?
rnoland: yeah, looks like maybe it needed libdrm_radeon..
soreau: My guess would be you need a different version of whatever provides radeon_bo_open
nanonyme: considers all abrupt positive events pleasant surprises even though they might be somewhat expected so he won't get disappointed with delays
rnoland: i'll do some checking... i wasn't going to enable libdrm_radeon in 2.4.12 for us... but maybe i need to...
nanonyme: Shouldn't r200 code be compatible with non-libdrm-radeon too?
soreau: /usr/include/X11/extensions/xfixesproto.h:51:34: error: X11/extensions/shape.h: No such file or directory <-- when trying to compile xorg-server from git
soreau: What do I need?
chithead: soreau: you are using an unholy mix of -9999 and non-9999 protos
soreau: chithead: I shalt be punished me lord? xD
soreau: has a look
soreau: Ah I prolly need x11-proto-xproto-9999 (instead of 7.0.14)
soreau: put a slash/in there somewhere
boghog: ah doh, need to compile against 2.6.28 of course
boghog: slaps self
agd5f: rnoland: libdrm_radeon shouldn't be required
agd5f: it only enables the kernel memory management stuff
Sarvatt_: soreau: libXext i think
soreau: Sarvatt_: I just installed x11-proto/xproto from git and recompiling X as we speak, so we'll see I guess
rnoland: agd5f: that was what i thought... i would only need it for ttm...
soreau: Sarvatt_: Thanks for that bit of info
soreau: Sarvatt_: Yup, still failed the same. Now compiling latest libxext
boghog: I only need the drm.ko and radeon.ko kernel modules from libdrm right?
rnoland: boghog: yes, but those still come from alex's branch afaik
boghog: yeah ok
boghog: hrm, any idea what this could be? magrathea /lib/modules/2.6.28-gentoo-r3/video # modprobe drm
boghog: FATAL: Error inserting drm (/lib/modules/2.6.28-gentoo-r3/video/drm.ko): Cannot allocate memory
boghog: probably pebkac
boghog: compiled from the r6xx-r7xx-3d branch
rnoland: boghog: i'm freebsd, so i'm not much help with that...
ferret_: boghog: any additional information in dmesg?
boghog: nothing in dmesg :/
boghog: well a bunch of missing drm_* symbols, but I think that was from when I tried to load radeon.ko first without having drm loaded
nanonyme: I'd try compiling r6xx-r7xx-3d from git manually, then insmod drm.ko and seeing if the behaviour persists.
nanonyme: If it doesn't, something's wrong with Gentoo buildsystem.
boghog: yeah that's pretty much what I just did, same error with insmod :/
nanonyme: Interesting. ^^
boghog: also made sure /usr/src/linux link is to /usr/src/2.6.28-r3 as well, if that matters
nanonyme: Assuming you don't have fglrx already loaded, sounds like nothing I've heard of.
rnoland: hrm, now i have the black screen issue...
soreau: So you guys on r6-7xx are simply testing 3D, not even with kms or dri2?
boghog: I do have libdrm-9999 installed through portage though, not sure if that matters, just compiling the kernel modules from git (r6xx-r7xx-3d)
nanonyme: soreau: It's kinda a good thing the DRM isn't yet ready for DRI2 so DRI1 gets enough testing too. ;)
soreau: I'm chrooted into my gentoo partition, installing all the dri2 bits for use with 2.6.31-r3 atm (for my rv350 ;)
soreau: hope it works
nanonyme: boghog: Should probably work.
boghog: oh hm, I might be doing something really dumb
boghog: ah no, thought i was loading the wrong modules after all but I wasn't :/
nanonyme: Also I suspect inbuilt DRM could also cause trouble.
boghog: hm, actually, I may have built half of the stuff against 2.6.31-rc3, which then errored, then I switched to 2.6.28 and finished the build
boghog: and make clean in the root drm dir didn't clean out linux-core
nanonyme: Yeah, it doesn't.
boghog: argh no, still same error
agd5f: boghog: make sure you unload your old dmr.ko and radeon.ko first
agd5f: modprobe -r radeon.ko
agd5f: also, make sure you don't have them built into your current kernel
boghog: ugh, I *did* have fglrx loaded
nanonyme: That's be a reason for the message then.
ferret_: I was about to ask about that again... ;p
soreau: So I'm aiming to get 2.6.31-r3 working with dri2 stuff.. should I build the kernel without DRM?
biotube: just modularize it
biotube: the kms stuff seems to be done in a linux git repo, so it'd just be a simple git-merge
nanonyme: soreau: Modular DRM and radeon kernel modesetting enabled in staging.
nanonyme: Oh, there's again a different preferred tree?
soreau: ../include/X11/extensions/XTest.h:34:35: error: X11/extensions/XInput.h: No such file or directory
soreau: While building libxext
nanonyme: Egh. Probably missing build dependencies. Could make sure you have all relevant dev files installed.
soreau: This is gentoo
soreau: I guess I might need xorg-server installed...
soreau: Though that's why I'm trying to build libxext is to get xorg-server to compile
nanonyme: Gentoo doesn't have an ebuild for the X server version you want? o.O
soreau: It does indeed. It just fails to build so far
nanonyme: Filed a bug for the ebuild already?
Sarvatt_: you need libxi 220.127.116.11+ for the Xinput.h soreau, but you cant build libxi 18.104.22.168 without the newer libxext
Sarvatt_: fun isnt it
boghog: yay, glxgears works, sort off
nanonyme: Sarvatt_: Well, it's just one header, surely you can pull it off from sources...
soreau: sure is
Sarvatt_: i'm in the middle of working it all out for ubuntu packages
boghog: screen turns black if I move my mouse over it
nanonyme: Erm, from a source tarball even.
soreau: Sarvatt_: Ahhhh
nanonyme: The library it wants to link against would be the real issue. ;)
boghog: but goes back to normal when I move it over another window
soreau: Sarvatt_: fwiw, thank you :)
boghog: and there's some flickering in the rendering
nanonyme: (if there even is a real issue)
Sarvatt_: if you can build libxi 22.214.171.124, then libxext, then the latest libxi git
rnoland: oh, hrm... yes it is causing the screen to go black when it goes into the foreground now...
soreau: Sarvatt_: Working on it
Sarvatt_: that routine worked for me, they're going crazy changing around all the depends in the past few days
soreau: Sarvatt_: I see what you mean now
boghog: and dragging my xterm over the glxgears windows cuases some corruption (outside the glxgears window)
nanonyme: boghog: And playing back a movie using Xv causes a lockup?
boghog: while running glxgears?
soreau: Sarvatt_: Would you be able to point me in the direction of libxi-126.96.36.199 ? It's not in portage, just 1.2.0, 1.2.1 and -9999
boghog: doesn't seme to cause a lockup, not 100% sure if totem is using Xv though
rnoland: agd5f: and now i'm seeing corruption as well.
Sarvatt_: ack no tarball for it up
nanonyme: boghog: Try mplayer in terminal and tell it -vo xv.
soreau: Sarvatt_: Where did you find it?
soreau: I guess I could git it then revert some commits...
nanonyme: boghog: Totem can be made to use Xv too though with gstreamer properties.
nanonyme: If it isn't.
rnoland: agd5f: also... if the gears window is partially offscreen it stops rendering...
boghog: nanonyme, no luckup that way either, though my cursor just got corrupted
Sarvatt_: yeah going to have to revert it by hand, i had it around following xserver master on git
nanonyme: boghog: Interesting.
agd5f: rnoland: I think the corruption is due to memcpy and bad cliprects
rnoland: or rather stops updating... it claims it is doing 58 fps...
boghog: and now it got uncorrupted :p
rnoland: agd5f: i wasn't seeing it before i switched to master and updated libdrm
soreau: Sarvatt_: Ok, let's see what I can do here. Thanks for the info
agd5f: rnoland: you mean corruption when you paritally cover the window?
agd5f: that's what I was referrring to
Sarvatt_: go back to around when they started using cookie events for XI2
rnoland: agd5f: now, when it starts or becomes the foreground window.. the screen blacks out.
rnoland: if i click on the desktop the screen returns.
rnoland: if I obscure the gears window then i get corruption over some portion of the screen
agd5f: rnoland: ok. I'm not sure what casues that yet. only seems to happen to some people
nanonyme: soreau: http://cgit.freedesktop.org/xorg/lib/libXi/snapshot/libXi-188.8.131.52.tar.bz2 how about this?
soreau: nanonyme: Um.. awesome...
rnoland: agd5f: well, like i said.. it was fine before i switched to master and updated libdrm
agd5f: rnoland: can you bisect?
rnoland: and libGL is now from current master build as well.
nanonyme: soreau: There's always links available for tagged versions in freedesktop cgit pages.
rnoland: agd5f: hrm, i can try...
soreau: nanonyme: You just saved me a lot of work (most likely) thanks
nanonyme: Well, the other alternative would have been to clone the sources and go back in history to the place where the tag for 184.108.40.206 resides.
nanonyme: Erm, clone the repo even.
nanonyme: Revision control is a friend. ;)
soreau: nanonyme: Could you by chance give me a link to xext-220.127.116.11 please or tell me how to find it?
boghog: my own opengl app segfaults when calling glGenBuffers
soreau: nanonyme: ./configure for libXi-18.104.22.168 seems to want ti
soreau: nanonyme: Awesome, thanks
nanonyme: Just do Google on git freedesktop, then search the component you need in the cgit main page.
nanonyme: That's what I do.
soreau: nanonyme: Ah, I see
Sarvatt_: oh dang, i didnt see the tarball for 22.214.171.124 on there because it was under 1.2.1, sorry :D
soreau: Gah DPMS.c:40:33: error: X11/extensions/dpms.h: No such file or directory
soreau: I guess I'll have to downgrade every component before upgrading them
nanonyme: Sarvatt_: Yeah, it's not in version order but time order.
nanonyme: Apparently 126.96.36.199 came out before 1.2.1.
boghog: ah it's actually focusing the window that makes the screen go black, not mouse over (since it doesnt do it with focus on mouse-over turned off)
soreau: So is this to say libxext might depend on an earlier version of itself?
soreau: Because when attempting to compile libxext-188.8.131.52 it fails with http://pastebin.com/m2bef5096
soreau: and afaict, the headers it's not finding in X11/extensions/ are from libXext
Sarvatt_: why are you compiling libxext-184.108.40.206?
soreau: Sarvatt_: Because libXi-220.127.116.11 asked for libXext >= 18.104.22.168
soreau: in ./configure
soreau: yea :/
soreau: I just hope it's not a pkgconfig thing, I can't stand pkgconfig dir issues
soreau: I have libXext-1.0.4 currently installed
nanonyme: So it's probably needing stuff that'll get to 1.1.0.
mcgreg: btw, die the Option "Clockgating" "on" and Option "DynamicPM" "on" work correctly? I have a new laptop and with or without these option the power consume seems to be same
Sarvatt_: 1.0.4 is almost 2 years old..
soreau: Well I can't seem to install a newer version of libXext or libXi (because of libXext's oldness)
nanonyme: I'd drastically file bugs, go check FAQ's and if that won't help, wait.
soreau: Well I have a feeling that even if I would have successfully installed everything it wont work anyway
nanonyme: You sometimes need a bit of terminal magick in Gentoo for updating some more troublesome components.
soreau: Yea, I could even.. do some black magic now that I think about it
nanonyme: And figuring it out by yourself is pain. :)
nanonyme: still remembers the libexpat mess *shudder*
Sarvatt: maybe downgrade xextproto to 7.0.5 then try it then upgrade it again before you upgrade libxext?
Sarvatt: upgrade libxext after compiling libxi 22.214.171.124 i mean, before you upgrade to libxext git head
Sarvatt: err xextproto
soreau: Sarvatt: Ok, I just got xextproto-7.0.5 installed
chithead: soreau: the problem is that header files have been moved around in the protos, so either run all git or none
soreau: chithead: Yea, but where do I start?
chithead: soreau: http://www.portagefilelist.de/
protocols: hi all
Kollapse: Hi, how come I can't play any games with radeon? Native games like sauerbraten
biotube: which card?
Kollapse: biotube, ATI Mobility X1400
Kollapse: latest radeon driver and xorg 1.6
Kollapse: I get messed up graphics
protocols: wasn't there a config option @xorg.conf so my mobile gpu ticks-down when not under heavy use to save battery ?
Kollapse: I can play 2D games but no 3D
protocols: i have a x1400 - works great
Kollapse: protocols, can you paste me your xorg.conf please ?
protocols: well actually I have some performance probs with tuxracer and some other games but could be some config I am messing with
biotube: Kollapse: try grep -i radeonhd /var/log/Xorg.0.log - if it returns anything, you're using a different driver
protocols: Kollapse: if you are using the current ubuntu distribution no xorg.conf changes are needed as everything will be detected automatically
Kollapse: protocols, I don't use ubuntu
protocols: what are you using?
protocols: well I guess it is x11 based?
Kollapse: protocols, of course :D
Kollapse: biotube, all RADEON
protocols: anyway.. dunno exactly since which version.. but I guess since 7.3 xorg.conf needs only little touch
Kollapse: protocols, still could you paste me your xorg.conf please ? :)
Kollapse: protocols, that's all ??
Kollapse: 16 lines wow, my xorg.conf is 147 lines : http://nopaste.info/5bc0f5ce85.html
Kollapse: a lot of comments but still no device section in yours
Kollapse: biotube, can you make any mistake from my conf ?
boghog: mines 28 without comments :/
boghog: 22 without empty lines :p
biotube: Kollapse: your xorg.conf looks like one from before X.org autodetected everything
biotube: I'd try moving it to something else and seeing how that worked out
Kollapse: biotube, as in without any xorg.conf ?
protocols: Kollapse: afaik setting all the misc options via xorg.conf is a deprecated way and should not be done as the best settings are auto-detected
Kollapse: is back
Kollapse: Tried without xorg.conf
biotube: any better?
Kollapse: Won't start X, complains about not being able to start in framebuffer mode and that it needs BusIDs for all devices
chithead: Kollapse: are you starting in chroot or something?
Kollapse: do you want my whole Xorg.0.log while running with the xorg.conf ?
soreau: chithead: Well I updated all proto components to -9999 and I still get the same errors as before when attempting to compile libXext
chithead: soreau: then it must be something moved out of protos
chithead: soreau: which file is missing exactly?
soreau: I just can't seem to get anything >libXext-1.0.4 to compile. Sec, I will pastebin the error
chithead: ../include/X11/extensions/XTest.h:34:35: error: X11/extensions/XInput.h: No such file or directory
soreau: yup, that would be the one.
soreau: That file is provided by libXext afaik
soreau: But the other key is, I have no xserver installed which is what I am ultimately trying to accomplish here
chithead: soreau: no, this file is now in >=libXi-126.96.36.199
soreau: chithead: Well I can't emerge that because it wants to pull in and compile libXext
chithead: try emerge -1O =libXi-9999
soreau: chithead: http://pastebin.com/m52f420ff
AndrewR: airlied, ping
chithead: it is O not 0
soreau: gah, that's an l
soreau: Oh, an O
chithead: 1O, not l0 or lO or 10
soreau: chithead: Sorry, here you go http://pastebin.com/m2911a701
chithead: hmm, too bad
soreau: I've tried every version of libXext I could and none compile
Sarvatt: libxi 188.8.131.52 requires libxext 184.108.40.206 which requires libxi >=220.127.116.11, fun stuff
soreau: I guess it is too bad
soreau: Oh well, thanks for trying
chithead: soreau: you can try the last version of inputproto which still comes with XInput.h
soreau: chithead: I have inputproto-9999 installed already
chithead: soreau: downgrade it
soreau: To what?
soreau: The only one I see is 1.5.1 or 18.104.22.168
soreau: and I'm trying to get X 1.6.x compiled
soreau: tries anyway
chithead: soreau: 1.4.3
soreau: oh my
chithead: 22.214.171.124 should also work
Sarvatt: you cant build libxi 126.96.36.199 against any of those which is a requirement for libxext though
soreau: Well shit. libXext finally compiled
chithead: now upgrade inputproto again before anyone notices :)
soreau: chithead: I don't think anyone noticed (libXi-9999 is now compiled, on to the real test of xorg-server :)
soreau: Well everything compiled but I'm still plagued by this error I've got on nearly every other gentoo kernel version. Can't mount NFS, like it can't find root or something *goes off in frustration ranting*
nanonyme: Hum, imo the most untrivial part of NFS is setting up the exports properly.
nanonyme: Other than that, pretty simple.
soreau: The problem is, it's trying NFS as a last resort. There is no NFS setup
soreau: It's like it can't find root which the same grub entry works for some kernel versions, but not for the ones you need it to
soreau: It's probably by far the most frustrating thing about gentoo or any linux distro I've ever experienced
soreau: It's very basic. Boot the kernel from the disk! and it's like, no I prefer to play dumb
soreau: I have had this problem over and over for over a year now and every time I look into it, I have to just use some other kernel version and sometimes it will work
DanaG: Here's something weird I get: I can't boot via grub-efi anymore -- it (the kernel) acts like it can't comprehend the ext4 partition.
tmerriam: i thought grub needed to be updated to support ext4 yet
DanaG: That's not the issue, actually... grub2 it is, and that sees ext4 just fine.
DanaG: I get this: Unable to mount root on unknown-block(0,0)
DanaG: or: "unsupported optional features" -- because it's trying to mount as ext3. Or: no init found.
nanonyme: Is Grub2 supposed to be usable?
biotube: last I played with it, all the keybindings were changed to random things
biotube: plus the font was hideous
nanonyme: biotube: Would be the internationalization and term support, I guess...
biotube: nanonyme: there's still no reason to change the keybindings - 'b' works about as well as whatever the hell they switched it to
nanonyme: Oh, you mean that way.
nanonyme: I thought you meant as in rebinding the keymap.
nanonyme: (as in, like eg you getting dvorak)
biotube: that would be a rather hideous bug
tmerriam: Dana: i found someone with that problem suggesting the devices arent named correctly, and another that says ext4 might be built as a module....
nanonyme: Imo it would a bit hilarious bug. ;)
biotube: so ugly it's funny :)
soreau: So I figured out my issue for the kernel, now in X session. But even though x log reports dri2 is enabled, glxinfo says sw rasterizer
soreau: I just started compiz.. and it is working.....
soreau: I wonder why glxinfo is misreporting
soreau: or if it isn't.. I don't understand
soreau: chithead: Anyway, thanks for the help. Things are looking good ;)
soreau: input is a bit screwy, think I might have to remerge some things
soreau: Should mesa be compiled with galium flag for dri2?
EruditeHermit: soreau: what does your xorg.conf read?
EruditeHermit: soreau: can you paste that?
EruditeHermit: soreau: I don't think you need gallium flag
EruditeHermit: soreau: my suspicion is that your xorg.conf says radeon instead of ati
soreau: EruditeHermit: Actually, there is no Driver line but X log loads ati which is loading radeon
EruditeHermit: can you post Xorg.0.log?
EruditeHermit: soreau: try adding a driver line with ati
EruditeHermit: just for fun
EruditeHermit: see if it does anything
soreau: TBH, what you're telling me doesn't make much sense :)
soreau: If ati loads radeon.. if anything I would think I should put Driver "radeon"
EruditeHermit: for kms/dri2 that doesn't work for some reason
EruditeHermit: atleast on Ubuntu
EruditeHermit: from my experience
soreau: Well this is gentoo and my keyboard input is a bit screwy but I have a suspicion as to why for that
EruditeHermit: evdev isn't loading
soreau: Nope, sure aint
EruditeHermit: soreau: did that help at all?
soreau: Well that was pretty cool. I am excited to know how to get glxinfo to quit reporting sw rasterizer as compiz+moving the glxgears window around works but compiz is still running as indirect-rendering
soreau: anywayz, gnite folks and thanks for all the help
EruditeHermit: Sarvatt: do you do your builds with gallium enabled/
EruditeHermit: is it possible to build with gallium and not use it?
EruditeHermit: or once built is that what is used?
Sarvatt: its not packageed, you can do it by hand sure
Sarvatt: just dont be silly and install it to /usr
EruditeHermit: I just wanted to maybe have the libraries around and be able to use them
EruditeHermit: to test
Sarvatt: yep i compile it in /opt/mesa every few weeks to see if it works yet and use this in .bashrc -- alias gallium='LD_LIBRARY_PATH="/opt/mesa/lib/" LIBGL_DRIVERS_PATH="/opt/mesa/lib/gallium"'
virtuald: how do i get rid of this blinking getty without an inittab?
virtuald: it pops up over x and disappears
virtuald: or is it some other console text
virtuald: it pops up as often as a getty restarts
virtuald: wrong channel