agd5f: MostAwesomeDude: feel free to merge you FP changes into the r500-support branch
MostAwesomeDude: agd5f: Once I can get 'em working in a sane manner.
MostAwesomeDude: I mean, I'm halfway to getting the plain textured shader working.
agd5f: MostAwesomeDude: :)
MostAwesomeDude: Until then, the r500test branch in my repo has my code.
MostAwesomeDude: At least the plain shader works.
agd5f: MostAwesomeDude: BTW, you can dump the first instruction in your dumb_shader
agd5f: it's wrong
MostAwesomeDude: agd5f: I figured as much. airlied says he got it by dumping fglrx, lawl.
MostAwesomeDude: It should be INST_TEX.
MostAwesomeDude: The dumb shader should be the shader in tex video.
agd5f: yeah, but without a tex, it causes problems
agd5f: 0x7808 is an ALU instruction
MostAwesomeDude: 'k, fixed. Now it matches the tex video shader.
MostAwesomeDude: agd5f: Hoy, in the docs, is SWIZ_UNUSED mean that that value just isn't used by the shader, or does it mean "ignore this swizzle?"
airlied: I just know I'm going to stab myself when I find this compiz on rs690 bug
MostAwesomeDude: airlied: We all have our difficulties. I'm still trying to figure out why consts and temps don't work right.
Magnade: airlied: then if you stab yourself now maybe you will find it quicker?
agd5f: MostAwesomeDude: in what instruction/reg?
airlied: Magnade: possible, I'm afraid to check how long is has been since I first found this bug.
airlied: that alone might drive me over the edge.
Magnade: airlied: what bug is this?
airlied: Magnade: compiz doesns't work on rs4xx/rs6xx
airlied: something is getting messssed up in the non-tcl code
MostAwesomeDude: agd5f: Just period. For some reason, the src.Index and dst.Index values don't work as temp regs. I think I'm not understanding something about the pixel stack.
MostAwesomeDude: I gotta change locations. I'll be back.
agd5f: airlied: I added the pipe setup my r345-cleanup drm branch
airlied: agd5f: cool..
agd5f: MostAwesomeDude: make sure you aren't selecting an inline constant
MostAwesomeDude: agd5f: No, there's a Mesa flag for inlines, and I'm not selecting that.
MostAwesomeDude: According to the docs, if REL and CONST are cleared, then the src/dest registers point to locations on the pixel stack.
MostAwesomeDude: The confusing thing is that not all of those locations are safe to use for temps.
MostAwesomeDude: Or at all.
agd5f: MostAwesomeDude: the MSB specifies an inline constant IIRC
MostAwesomeDude: agd5f: Right, and the bit beside that is REL and it sets whether the src/dest addr is relative.
MostAwesomeDude: !
MostAwesomeDude: Would it be bad to always set REL?
MostAwesomeDude: I mean, for GPGPU it would be bad, but for us, could we set it?
MostAwesomeDude: I'm gonna go try that right now.
agd5f: not sure
agd5f: MostAwesomeDude: YOu should probably only do that if you're using the loop variable
MostAwesomeDude: agd5f: Yeah, doesn't help.
MostAwesomeDude: We don't actually set US_PIXSIZE anywhere, do we...
MostAwesomeDude: Size of the pixel stack.
MostAwesomeDude: Gah.
airlied: ugggh projective coords.
airlied: I probably should read the book :-P
MostAwesomeDude: airlied: XD, yeah.
MostAwesomeDude: Too tired to write more code. Maybe tomorrow.
MostAwesomeDude: Night, all.
rx__: night
airlied: wonders if anyone has compiz on r200 and could try setting R200_NO_TCL before X starts
airlied: so that the indirect GL runs with no tcl
airlied: damn I know lots about prespective and viewport transform but still have broken compiz ..
MrCooper: airlied: still the warped textures?
airlied: MrCooper: yup..
airlied: wierdly it only happens when i'm supplying position and texture
airlied: when it supplies a color as well it seems to work better
MrCooper: airlied: do rectangle textures work fine otherwise, e.g. the Mesa texrect or yuvrect tests?
airlied: yup.
airlied: MrCooper: the main prob I have it finding a demo that breaks.
airlied: I'm going to write an attempt at another one..
MrCooper: maybe a pixel shader input routing issue?
airlied: I'd been assuming up until now I wasnt using a frag shader now I think I might be wrong :)
airlied: hmm no frag shader in use.. arrggh... it must be rasteriser or frag routing.
mcgreg: hmm I wonder whats wrong now. I git clones the new repo, and compiled ... "the Xorg log says -> (II) GLX: Initialized DRI GL provider for screen 0" but glxinfo says there is no?
mcgreg: there is no clear error in there, DRM is okay, AIGLX is okay
MrCooper: mcgreg: glxinfo says there is no what?
mcgreg: the usual : direct rendering: No (If you want to find out why, try setting LIBGL_DEBUG=verbose)
MrCooper: so did you try what it suggests?
mcgreg: doing "LIBGL_DEBUG=verbose glxinfo" ?
mcgreg: yeah I did
mcgreg: no change, it teels me nothing more
MrCooper: sounds like the wrong libGL - what's the renderer string?
mcgreg: OpenGL renderer string: Mesa X11
mcgreg: OpenGL version string: 2.1 Mesa 7.1
mcgreg: hmm I might have an idea
MrCooper: that's the standalone software X11 libGL
mcgreg: brb
mcgreg: works, it probably loaded an olger libGL , you were right
mcgreg: unfortunately glxgears still wont work ;)
mcgreg: still getting that odd error "drmRadeonCmdBuffer: -22"
MrCooper: mcgreg: btw, no need to restart X for changing libGL or even the client-side 3D driver :)
mcgreg: oh
mcgreg: didn't new that :)
MrCooper: mcgreg: there should be something in the kernel output
mcgreg: indeed :)
mcgreg: [drm:r300_do_cp_cmdbuf] *ERROR* bad cmd_type 9 at ffff81007b4cc474
mcgreg: any helpful to you? ;)
MostAwesomeDude: Morning, everybody.
MostAwesomeDude: Does anybody have any objections to me committing the r5xx shader to r500-support in the main tree?
tulcod: MostAwesomeDude: ...
tulcod: why :P
tulcod: as in
tulcod: why would we
MostAwesomeDude: tulcod: 'Cause it's not finished yet. It's gonna make some stuff look really weird.
MostAwesomeDude: To be fair, "weird" is a step up from "black screen..."
tulcod: MostAwesomeDude: meh, that's what you get from git versions....
MostAwesomeDude: Yeah. Okay. Merging now.
tulcod: as long as the releases have it sort-of-fixed
MostAwesomeDude: Okay. r500-support now has a semi-working r5xx FP shader.
MostAwesomeDude: I finish that, and we're pretty much done.
dli: MostAwesomeDude, is it closer to compiz now?
dli: r500_fragprog.c:94: error: ‘for’ loop initial declaration used outside C99 mode
MostAwesomeDude: Oh, and I saw this with glxgears and TCL enabled. agd5f, might be interested? Screenie: http://home.aweenet.net/~simpson/snapshot47.png
MostAwesomeDude: dli: Yes, we're closer.
MostAwesomeDude: Hmm, lemme fix that.
MostAwesomeDude: dli: I'm not seeing that error, especially since there's no for loop at line 94. I'm rebuilding the entire tree to see if I missed anything.
dli: MostAwesomeDude, let me fix it :(
MostAwesomeDude: 'k.
MostAwesomeDude: Yeah, I'm not seeing any build errors.
MostAwesomeDude: Are you using stronger warnings than me?
dli: MostAwesomeDude, doesn't matter, just fix it, wont hurt anyone: http://pastebin.ca/1006087
MostAwesomeDude: dli: Pushed. Also fixed the other ones.
MostAwesomeDude: I forgot that not everybody is on C99, lawl.
MostAwesomeDude: I guess I'm just too used to C++.
agd5f: MostAwesomeDude: looks good
dli: MostAwesomeDude, yes, built smoothly
MostAwesomeDude: agd5f: Did you see the incorrect faces on the inside of the red gear?
dli: MostAwesomeDude, glxgears fps reduced by 10%
MostAwesomeDude: dli: Compared to r345-cleanup?
MostAwesomeDude: What did you get before?
agd5f: dli: gears is not a beanchmark :)
dli: MostAwesomeDude, 2150 -> 1940
dli: agd5f, I know
MostAwesomeDude: dli: I went from ~2000 to ~2500 with cleanup. Also, GINAB.
dli: MostAwesomeDude, let me verify this
agd5f: MostAwesomeDude: yeah. I haven't seen that here. we may need to tweak the vap setup a bit, chip to chip
MostAwesomeDude: agd5f: It almost looks like gears isn't correctly describing the stuff to draw, but it draws fine w/o TCL.
agd5f: MostAwesomeDude: try playing with vap_cntl in r300_state.c
agd5f: MostAwesomeDude: also: https://bugs.freedesktop.org/show_bug.cgi?id=15386
MostAwesomeDude: Hmm.
dmb: airlied: got glxgears running!
dmb: http://img501.imageshack.us/img501/5721/screenshotglxgearshx1.png
rx__: eh.. what hw?
dmb: r515
rx__: oh not that interesting ;
rx__: ;)
dmb: for me it is
dmb: rx__: is it supposed to look like that right now you think?
rx__: not sure if it's supposed to look like that exactly
rx__: but some things are still missing..
rx__: that's for sure
roh: uhm...
dmb: also, found what may be a bug, if you use vesafb and an opengl app with r515, using a gl app hard locks the computer :D
roh: well.. is there some wikipage how to reproduce that? ive tried compling drm, mesa, dri and xorg-ati yesterday but got problems with some symbols
roh: i am on r515 (tp60p)
dmb: i did http://dri.freedesktop.org/wiki/Building
dmb: rx__: i'm not using the latest git for ati driver itself, maybe that could change things?
rx__: are you using x11 server dev packages?
dmb: probably not
rx__: it might.. lots of things change in git
dmb: rx__: nope, 7.2
dmb: roh: just follow the guide for http://dri.freedesktop.org/wiki/Building
roh: (EE) AIGLX error: dlsym for __driCreateNewScreen_20050727 failed (/usr/lib/dri/r300_dri.so: undefined symbol: __driCreateNewScreen_20050727)
rx__: oh.. heh
roh: found this in my x-log
rx__: that explains the recent interest in r500 drm..
rx__: it was blogged about :P
dmb: yup
dmb: roh: aiglx is not going to work with it yet
roh: rx__ interrest? of course. not because of blogs, but because fglrx stopped working completely and after ive had xrandr working unaccelerated with 2 heads i didnt want to leave that away
rx__: :/
roh: dmb ok.. thats fine. how can i disable it properly? Option "AIGLX" "off" in ServerFlags ?
rx__: AIGLX shouldn't affect anything ...
dmb: roh: you don't need to disable it, it just diabled it for you with that message
roh: i am mostly interrested in a) working and usable 2d (no skippy scrolling in the browser)
rx__: what's b) ? ;)
roh: b) is working xvideo
roh: 3d is only interesting for google earth
roh: ;)
dmb: don't you get that with drm (and not dri)
roh: dmb well.. THIS x currently sucks.
roh: switching workspaces is extremely skippy
dmb: fgrlx :D
roh: sometimes it takes seconds to render the borders now
roh: dmb as is said: doesnt work at all anymore.
dmb: fglrx doesn't work?
roh: dmb and does NOT have working multihead or xv
dmb: i thought fglrx had xv
roh: not working properly.
roh: its skippy and broken.
dmb: the r5xx dri stuff is all experimental
MostAwesomeDude: dmb: Have you checked out Mesa and DRM in git?
dmb: doesn't work very well yet
roh: and does advertise colorspaces it doesnt correctly convert then
MostAwesomeDude: dmb: Most of it works pretty well.
dmb: MostAwesomeDude: yes
dmb: MostAwesomeDude: you have an r5xx?
rx__: yes he does
dmb: MostAwesomeDude: glxgears prints out fine?
MostAwesomeDude: dmb: Yep. A r530, to be precise. And I've got pretty gears running.
dmb: :(
roh: ive got mesa, drm and xorg-drivers-ati from git yesterday
dmb: i'm compiled latest xf86-video-ati
rx__: he's actually playing with the shaders :)
MostAwesomeDude: The Mesa branch is r500-support, and the DRM branch is r345-cleanup.
dmb: i used master for drm branch
roh: ah.. i di not selct any brances specifically
MostAwesomeDude: dmb: That would be it.
dmb: you think -cleanup fixes it?
rx__: cleanup is the one you want to try out
MostAwesomeDude: All of the cool stuff airlied, agd5f, and I have been working on are in those branches.
dmb: ok, i shall try
roh: http://dri.freedesktop.org/wiki/Building looks a bit outdated... mesa has autoconf
roh: also it doesnt note changing to any branches. just clone
dmb: MostAwesomeDude: i guess -cleanup is in agd5f's repo?
rx__: http://cgit.freedesktop.org/~agd5f/drm/log/?h=r345-cleanup
MostAwesomeDude: dmb: Yeah, I think it is.
rx__: that one...
rx__: and i think this one...
rx__: http://cgit.freedesktop.org/~agd5f/mesa/log/?h=r500-support
MostAwesomeDude: Use `git pull origin
roh: http://pastebin.org/33653
MostAwesomeDude: rx__: We merged. http://cgit.freedesktop.org/mesa/mesa/log/?h=r500-support
roh: MostAwesomeDude eh.. on which repos. i have 3 checkouts here. usually i do git pull -u to update these
roh: one is mesa, one is drm, one is xorg.
rx__: ohh
rx__: didn't see that
rx__: sorry
MostAwesomeDude: roh: You can use a variety of things to get new branches. Most correct is `git checkout origin
MostAwesomeDude: If you're only pulling and not making local changes, then git pull will work fine.
roh: do i need that -u?
MostAwesomeDude: looks in the man page
roh: http://dri.freedesktop.org/wiki/Building should be udated with the correct pull commands then, does it?
rx__: huh... i don't see pull in that article
MostAwesomeDude: You're not supposed to use -u, apparently.
roh: no thats just what i thought was right
dmb: this is why i'm a mercurial fan :D
roh: hehe.. hg is cool.. atleast it doesnt hate humans who are trying to do something ;)
MostAwesomeDude: Okay, got it. `git checkout
MostAwesomeDude: I'm still trying to get the hang of git, myself.
roh: MostAwesomeDude ok. and how does one update that checkout then if there is already one?
dmb: yeh, its veyr confusing
roh: or switch a already checked out tree to another branch
MostAwesomeDude: roh: Okay. `git-checkout` only works on already existing trees.
roh: *sigh*
MostAwesomeDude: For example: (cd /usr/src/mesa; git checkout origin r500-support)
roh: does it checkout that to a new directory then or in the tree i have?
rx__: updating.. is just `git pull` once you switched branch
MostAwesomeDude: roh: That will checkout the branch into the tree.
roh: ok
MostAwesomeDude: And `git branch` will list your local branches, and tell you which one you are on.
dmb: dmb@alpha:~/Projects/drm$ git checkout origin r345-cleanup :error: pathspec 'r345-cleanup' did not match any file(s) known to git.
dmb: Did you forget to 'git add'
roh: error: pathspec 'r500-support' did not match any file(s) known to git.
MostAwesomeDude: Oops, spelled it wrong.
MostAwesomeDude: `git checkout origin/r500-support`
MostAwesomeDude: Sometimes I find it hard to believe that Linus himself wrote this.
MostAwesomeDude: That slash means "branch r500-support, at repo origin."
roh: MostAwesomeDude hehe.. he sure has a cruel humor sometimes
roh: ok.. mesa to origin/r500-support
MostAwesomeDude: roh: Yeah. "If it doesn't make you want to embed your keyboard in your monitor, it's not real programming."
roh: what about drm and xorg? which trees to choose there for a r515
MostAwesomeDude: r345-cleanup on DRM is right.
MostAwesomeDude: To be honest, my laptop hates Xorg 1.4/git, so I'm on Xorg 1.3
MostAwesomeDude: It doesn't matter, although you will need to get the DRI2 proto from somewhere if your Xorg is old.
roh: MostAwesomeDude r345-cleanup also for the r500?
rx__: on drm.. from agd5f's repo
dmb: yup
roh: how does that stuff depend on each others? so which order should i build it to link to the correct version?
rx__: hrm.. drm is a kernel thing.. i don't think order matters for that (?)
MostAwesomeDude: Build Xorg, install Xorg, build DRM, install DRM, build DRM modules, install DRM modules, build Mesa, install Mesa.
MostAwesomeDude: Xorg will need a Mesa tree to build itself, but you do NOT have to build it against your git Mesa tree.
dmb: or be lazy like me, and not build and install xorg at all :D
MostAwesomeDude: dmb: Yeah, I'm just using my distro's Xorg.
dmb: same
dmb: brb, trying it out
roh: how to select agd5f repo on drm?
rx__: you have to clone his repo..
rx__: git://people.freedesktop.org/~agd5f/drm
roh: i have a repo cloned from git://anongit.freedesktop.org/git/mesa/drm
roh: ignore that.. fast ip in europe is bliss
dmb: much better
MostAwesomeDude: Huh. Whoever did the last VAP fix, good work; fixes some of the gears problem spots.
MostAwesomeDude: Composite and 3D just don't play well together yet.
dmb: gears come out perfect for me
MostAwesomeDude: dmb: Sweet!
dmb: :D
MostAwesomeDude: >:3
rx__: now i'm curious.. :(
dmb: zsnes makes some pretty pictures on the screen though :D
rx__: i want to see what the frag prog does
MostAwesomeDude: rx__: progs/fp has FP tests.
roh: which branch on x should i use? git://anongit.freedesktop.org/git/xorg/driver/xf86-video-ati i think i have 'master' there
MostAwesomeDude: So far, tri-sub and tri-tex are perfect.
rx__: master should be ok
MostAwesomeDude: glxgears' shader is perfect, too.
dmb: xmoto is almost showing
MostAwesomeDude: I should make a list of progs that work with r5xx.
MostAwesomeDude: Basically, textures work, but the temp registers don't, so Mesa's default textured shader is busted.
MostAwesomeDude: The non-textured shader (glxgears) works fine, though.
MostAwesomeDude: I really wish I could use fglrx and dump some of their programs to see what they do.
MostAwesomeDude: On the other hand, of course, their shaders have buggies too.
dmb: whats try-sub and tri-tex?
dmb: ah, in the progs thing
MostAwesomeDude: ...Yeah.
dmb: i can't find tri-sub and tri-tex
MostAwesomeDude: You have to make in that directory; they're not built with the rest of the suite.
dmb: yeh, i did make them
MostAwesomeDude: Hmm.
dmb: there are some other tri's, but not tri-sub and tri-tex
MostAwesomeDude: In progs/fp?
dmb: tri-tex-3d
dmb: thats it i think
MostAwesomeDude: !?
roh: MostAwesomeDude when you mean composite and 3d dont play togethzer.. should i disable composite?
dmb: try-tex doesn't work for me
dmb: unless i have a window drag over it
MostAwesomeDude: roh: Well, right now the 3D is drawn to the screen very directly when Composite is on, so it won't behave as you want.
MostAwesomeDude: And the fp tests sometimes don't draw.
MostAwesomeDude: But stuff like gears, that draws many frames in a row, will work-ish.
roh: i _think_ i do like a bit of 3d more than what composite can help me with ;)
dmb: oh boy, xv is not very fun
roh: do i still need to selct EXA in the config?
MostAwesomeDude: dmb: http://home.aweenet.net/~simpson/snapshot48.png
MostAwesomeDude: Also xv should work fine, it uses a different 3D path.
dmb: hmm
dmb: maybe that requires latest xf86-ati
MostAwesomeDude: Yeah.
MostAwesomeDude: agd5f did a really good job on xv, it even behaves with Composite.
dmb: brb, testing
MostAwesomeDude: I've gotta go to a gig, so I'll be back online later.
MostAwesomeDude: Good luck, guys.
dmb: much better
dmb: yup, still no tri-tex working
dmb: unless i rub the window on top of it
roh: uh.. yeah.. gl is working
roh: 1900fps on glxgears
roh: hmm.. the flickery lines stay
roh: but they are not there aslong as i do not activate the second head as right-of
roh: when i leave it cloned the flickering isnt there
dmb: roh: you got 1900fps on glxgears!!!!
roh: dmb well.. yeah.. but the 'slow workspace switching' and the corruption/flickering of my mouse cursor is there
dmb: don't know, what distro?
roh: and its really blocky when firefox does its thing and bombards the x with expose events on some pages
roh: dmb ubuntu gutsy as base
dmb: oh
dmb: is 4891 frames in 5.0 seconds = 978.017 FPS really slow?
roh: i used tormod builds for some time in between
roh: do_wait: drmWaitVBlank returned -1, IRQs don't seem to be working correctly.
roh: trying googleearth
dmb: roh: i see a bug where when i move scrollbar in firefox, the screen flickers
dmb: roh: r5xx 3d is at the beginning stages
roh: dmb http://kor.gazaxian.com/index.php/category/dj-sets/
roh: load this ... completely blocks my browser on 100%cpu on one core for a moment and then depending on how accelerated the x11 is some more or not
dmb: roh: does the same for me
roh: heh.. cool.. a testcase
dmb: note that firefox doesn't do any acceleration stuff
roh: well.. with my eee-pc it loads fine
roh: dmb i know. but x11 shouldnt kill the experience just because it gets a few more braindead expose events from one app
dmb: hmm
roh: and other xdrivers seem to cope fine
dmb: yeh, i would like to test that with fglrx also
roh: heh.. googleearth bombs
dmb: google earth is actually working for me
dmb: just really really really slowly
roh: testing fglrx is senseless. it is and was always broken
roh: Warning, RV530 detected, 3D HAHAHAHAHA!!.
dmb: its gotton a little bit better
roh: 530? since when did it have that?
dmb: roh: i think thats the revision your using
dmb: of the card
dmb: revision of your cards chipset*
roh: M56GL [Mobility FireGL V5250] 1002:71d4
roh: should be a 515 i thought x1600 stuff
dmb: that might be a bug
dmb: i don't know the which one is which though
roh: the whole naming of gpus for all vendors i know of IS a bug
dmb: yes
dmb: i agree
dmb: especially ati
dmb: its so confusing
roh: xv seems to work here
roh: but lots of the mesa test programs crash
lymeca: I have a ATI Technologies Inc R480 [Radeon X850XT (PCIE)]
lymeca: I'm currently using the latest version of xserver-xorg-video-ati in Debian
lymeca: I'm getting unusable performance in Compiz Fusion though.
lymeca: I was under the impression that these drivers would support this card with full 3-D
icewaterman: lymeca: what did you smoke? full 3d support is not available for any radeon beyond 9200.
icewaterman: there is good 3d support with your card (i have the same one) even with 6.8 version of the driver
mattst88: define 'full'
icewaterman: mattst88: well all acceleration features the card supports are available and it doesnt crash due to driver issues :)
icewaterman: in case of full 3D support that of course only applies to 3D capabilities
dli: "mplayer -vo gl2" works now, basically, some blinking pixels still, "mplayer -vo gl" still not
dli: no luck with gnash opengl renderer
roh: well.. when the occational stalling on workspace switching vanishes and xv gains vsync capabilities i would be happy
roh: ah..and mousecursor flickering with xrandr multihead still sucks