simpsonc: Hmm. I think I know where it is; it's in the new code for pix shaders, where a cmd is nulled out and then conditionally filled.
agd5f: untested render support for r5xx pushed to my personal repo: http://cgit.freedesktop.org/~agd5f/xf86-video-ati/log/?h=r3xx-render
rx__: :)
rx__: i was expecting tmw but wow :P
rx__: hops on notebook
airlied: rx__: it gives black boxes :)
rx__: :/
airlied: fixed it..
rx__: same branch?
airlied: http://people.freedesktop.org/~airlied/r500_render_fix.patch
airlied: rx__: just apply that on top.
airlied: agd5f: ^^^^ when you wakes up
rx__: alrighty
airlied: time for bus bbl maybe.
rx__: thanks guys
rx__: hrm
rx__: text is garbled on gdm
rx__: and what would normally be *s for password is blank..
rx__: it's even worse when logged in
rx__: :/
rx__: i guess i should be concise
rx__: text on buttons in gdm are garbled
rx__: other text in gdm are fine
rx__: will test tmw
airlied: rx__: did you add my patch?
airlied: rx__: sounds like what happened before it
airlied: hmm maybe my fix isn't quite a fix :)
airlied: on this laptop it apeears less successful
airlied: but it worked at home.
airlied: at work even.
airlied: agd5f: so on my X1950 it was all okay, however on my M56GL bonghits
glisse: agd5f: what was the bug ?
glisse: agd5f: ok got it this was this tex coord routing things
glisse: i keep forgetting about this
glisse: airlied: i think you got unused big dell screen on your desk, send them to me asap ;)
airlied: glisse: I need a 4 monitor setup :)
mcgreg: 4? what the heck do you do with 4 monitors? :)
glisse: mcgreg: so when he plays quake in can see in 4 directions ;)
mcgreg: hehe
mcgreg: that one was good ;)
glisse: feel lonely with its 17" where you can't but aside two xterm without overlapping
glisse: s/but/put
airlied: mcgreg: I have 2x 16xPCIE slots and 2 x 2XDVI cards..
airlied: what could possibly make me not want to play with 4 monitors :)
mcgreg: not having enough space ;)
airlied: mcgreg: new office so I have lots of space :)
airlied: glisse: the r500 code works on one variant, but on my laptop I get lots of triangles :-(
glisse: airlied: which codee mesa ? ddx ?
airlied: glisse: render accel.
glisse: btw i just noticed that RS* are different on r500
airlied: glisse: yeah different places..
airlied: and layouts
glisse: airlied: so this is vap not working if you got lot of triangles ?
glisse: or somethings in the rasterizer ?
airlied: glisse: yeah it might be in the VAP, but then I never have a clue :)
airlied: I disabled VAP and I get tris more..
airlied: I'll put it back and see what it did..
airlied: hates vps, no point using them for render :)
glisse: i got some freetimes my account on cluster have been suspended for unknown reason so i am waitingg for people to tell me why....
airlied: glisse: did you fill the disk again?
glisse: i likely abused the cpu time slice i was allowed to use
glisse: and maybe also i bringed down the network due to heavy transfert :)
airlied: more triangles :-(
airlied: I blame RS :)
airlied: need to get a better list of what is different between various r50s
airlied: r500s even.
glisse: airlied: btw what are the 2 models you have ?
airlied: glisse: X1950 and M56GL (FireGL)
airlied: the x1950 has a lot more cores, I wonder do I just have misconfigured pipes etc..
glisse: likely somethings like that
glisse: i wouldn't expect the 3d cmd to be different
glisse: where is the init 3d state function already ? using cgit ain't easy to grep
airlied: radeon_commonfuncs.c
airlied: and radeon_exa_render.c
airlied: both have bits
airlied: ah well I'm gonna bed.. l8rs.
glisse: good night
icewaterman: uhm, when i switch from windows to linux my monitor content is slightly moved to the left, i have to auto-rearrange it, in order to have it in the correct position. this is unnecessary with the fglrx driver. might that driver be using another modeline?
glisse: icewaterman: what card ?
icewaterman: glisse: X850XT
icewaterman: glisse: i had the same problem with a radeon9700pro
glisse: i believe we do program CRTC_H_SYNC_STRT_WID differently than fglrx
icewaterman: glisse: i'll try some other modeline fglrx used.
icewaterman: brb
glisse: icewaterman: modeline won't change
glisse: usesomething like radeontool to get the value of this register for same mode under fglrx and and under radeon
glisse: and compare the two
glisse: the first few bits are likely differents
icewaterman: glisse: well, i'd rather like fglrx to stay away from my box as far as possible.
icewaterman: probably thanks to fglrx i cannot use 3d in 32-bit apps anymore
glisse: icewaterman: just use the fglrx ddx to get the value of this reg for the mode where this is the more obvious
glisse: it might not be noticeable with some mode because rounding might lead to same value
icewaterman: glisse: i do not use windows that often, so i can live with that
icewaterman: what really annoys me is that 32-bit 3d apps are only useing software emulation while 64bit apps work quite well with the radeon driver
glisse: icewaterman: still would be nice if someone try to figure if this is the case
glisse: i know that i see that too but i am just too lazy
icewaterman: glisse: what do you know, the 32-bit issue or the monitor issue?
glisse: icewaterman: 32bits app shouldn't have anyproblem with dri
icewaterman: glisse: maybe fglrx driver modified some libraries
glisse: i know that r400/r300/r200 program a mode slightly shifted compared to what produce other card on my monitor
icewaterman: glxgears works fine, tremulous works fine, glxinfo output looks correct, all 32bit apps are extremely slow (wine apps seem to use software emulation)
glisse: icewaterman: well try to build a 32bits version of glxinfo and glxgears to check
icewaterman: glisse: not yet
icewaterman: glisse: do i need mesa32bit for those apps?
icewaterman: maybe i accidentally removed those libs and forgot to reinstall them
glisse: icewaterman: likely need them
icewaterman: glisse: but why did i never notice this problem with the radeon9700pro before?
glisse: icewaterman: the 32bits problem or monitor problem ?
icewaterman: glisse: the 32bit problem. the monitor problem has been there all the time, as long as i've been using radeon driver on some r200 card several years ago
icewaterman: glisse: direct rendering: No <-- says the 32bit glxinfo
glisse: then GL_DEBUG=verbose glxinfo32bits
glisse: to see the issue
icewaterman: glisse: same output
glisse: icewaterman: at the top
glisse: output should be more verbose :)
icewaterman: ah, it now wants LIBGL_DEBUG=verbose glxinfo
glisse: sorry forgot the LIB prefix
icewaterman: hm, nothing
glisse: icewaterman: pastebin whole output
icewaterman: omg, it printed the debug output to stderr
icewaterman: which is why |less didnt show it
icewaterman: http://rafb.net/p/BwxhUL93.html
icewaterman: now with the additional info
icewaterman: the file is there, it just complains about the wrong elf class
glisse: icewaterman: well you need 32 bits version of mesa driver
icewaterman: glisse: didnt need it in the past
glisse: i guess that 64bits are in /usr/lib64/....
glisse: icewaterman: well in the past they where their
icewaterman: glisse: ?
glisse: icewaterman: i don't think a 32bits program can run against a 64bits lib, this would astonish me
icewaterman: glisse: the driver is there btw.
icewaterman: just noticed it
glisse: yes but its compiled for 64bits
icewaterman: but they seem to be in /usr/lib32/
glisse: wrong ELF class: ELFCLASS64
icewaterman: glisse: yes, but the 32bit drivers are in /usr/lib32/dri/
glisse: then you can change ldpath to check /usr/lib32 when launching 32bits program
icewaterman: glisse: so it was probably the fglxr driver after all who caused this problem by deleting some symlink or so
glisse: distribution likely changed the way they setup userspace on 64bits system and default to 64
icewaterman: glisse: no, this has been gutsy since last octobre and was running fine (different mainboard and card but still amd64)
icewaterman: brb
glisse: icewaterman: so does LIBGL_DRIVERS_PATH=/usr/lib32/dri glxinfo32bit works ?
icewaterman: glisse: yes
icewaterman: so for some reason that environment variable got canned by the fglrx driver or whatever
icewaterman: dunno how ubuntu deals with this
glisse: icewaterman: no i believe this is somethings distro related, likely a package update breaked somethings
icewaterman: glisse: guess so
icewaterman: glisse: unlikely a package update (since xorg hasnt been updated afaik)
icewaterman: but maybe fglrx did remove something that wasnt meant to be removed
glisse: well this more related to mesa/gl/... packagesa
icewaterman: yepp, gonna ask the ubuntu guys. worst case scenario is i have to reinstall xorg
agd5f: airlied: pushed! thanks!
GhePeU: hi. I did some tests with agd5f's r3xx-render branch on my x550
agd5f: GhePeU: any luck?
GhePeU: so far it works: no graphic corruptions or rendering errors
GhePeU: render_bench is faster than before: WAY faster
agd5f: GhePeU: cool :)
GhePeU: faster than imlib2 for the first time
GhePeU: for example: Test Xrender (offscreen) doing general smooth scaled Over blends from 28.619 sec to 0.225 sec
GhePeU: Test Xrender doing general nearest scaled Over blends from 9.208 sec to 0.718 sec
GhePeU: then the problems: x11perf -aa10text
GhePeU: with compiz before 103000 char/s, now 21800 char/s
GhePeU: with metacity from 113000 to 22800 char/s
glisse: does the optimization of grouping font in a big texture have been made driver specific ?
agd5f: glisse: I think that's server side
glisse: i think too
GhePeU: using 1.4.1 here
GhePeU: sorry, 1.4.0.9
GhePeU: then there's another problem: the server randomly crashes when switching to console with compiz and metacity with compositor enabled
agd5f: GhePeU: the VT switches should be fixed in master
agd5f: I just haven't synced my branch yet
agd5f: GhePeU, glisse: http://cworth.org/exa/i965/eliminating_glyph_fallbacks/
GhePeU: commit "RADEON: Revert to old behavior when resetting the memmap on VT switch" ?
agd5f: GhePeU: yes
GhePeU: I'll apply it locally and report
agd5f: GhePeU: thanks!
GhePeU: restarting X...
glisse: agd5f: well we would need profiles to see where the culprit is for radeon
agd5f: glisse: definitely
GhePeU: ok, it works now
GhePeU: had to reboot because the previous crashes left the console messed up but now it works
agd5f: GhePeU: excellent!
GhePeU: I don't know, I've got a tar.gz dated august 2005 and I'm still using it
icewaterman: wow, that was funny, ever since i have a multi-core processor, some games run twice as fast :)
icewaterman: most likely because of the on-demand scheduler reducing clock frequency
hosler: k im back
hosler: who wants to help me with my dri problem some more, lol
glisse: hosler: where are you now ? drm & radeon module load ed and work ?
hosler: i got to the point where drm is working correctly and there is /dev/dri/card0
hosler: and radeon module works too
hosler: glxinfo gives me this
glisse: hosler: and X server is happy too ?
hosler: name of display: :0.0
hosler: unknown chip id 0x791f, can't guess.
hosler: libGL warning: 3D driver returned no fbconfigs.
hosler: libGL error: InitDriver failed
hosler: let me check xorg log
glisse: hosler: well you likely need mesa from git hopefully airlied pushed your pciid their too
hosler: ok whats the command. sorry for being a noob, but git is new to me
glisse: git clone git://anongit.freedesktop.org/git/mesa/ cd mesa make linux-dri
hosler: git failed
hosler: remote hungup unexpectedly, how rude
icewaterman: hm, after ~20 minutes of gaming, my systems hardlocks
MrCooper: hosler: .../git/mesa/mesa
icewaterman: this however does not happen on windows, i can run 3dmark* as long as i like
hosler: k thanks
hosler: ok so now what needs to be replaced?
agd5f: partymola: try running a 3D app, that should "fix" render accel
hosler: glisse: make[6]: *** [../common/dri_bufmgr.o] Error 1
hosler: glisse: what make options do i pass so it only does radeon? it looked like it was compiling for a lot of cards
icewaterman: btw. is that a problem that the drm and radeon kernel module are quite old in current linux kernels?
agd5f: icewaterman: doubtful. not much has changed
hosler: glisse: this error happened while trying to compile the i915 driver
MrCooper: hosler: make DRI_DIRS=r300
hosler: so
hosler: make DRI_DIRS=r300 linux-dri
hosler: that command?
MrCooper: hosler: make linux-dri is only needed once, now just make DRI_DIRS=r300
agd5f: hosler: you can also force the driver to treat you card like the other rs690s. just add:
agd5f: ChipID 0x791e
agd5f: to the device section of your config
MrCooper: agd5f: that won't help for Mesa, will it?
hosler: agd5f: yeah i read that somewhere. mesa failed again
hosler: i guess ill try that
agd5f: MrCooper: doesn't the chip id get passed to mesa via the ddx?
MrCooper: not sure - I thought it wasn't, but it might
hosler: ill try it
agd5f: hosler: you still may need a newer mesa, depending on what you have installed
hosler: ok
hosler: hold on ill be back
icewaterman: btw. i need to compile i686 version of radeon driver on amd64 platform. any idea how i can do that without cross-compiling?
icewaterman: i686 kernel can be compiled without cross compiler as well
icewaterman: so it is possible
MrCooper: icewaterman: make linux-dri-x86
hosler: ok so that chip id you gave me wasnt recognized in my current version of mesa
hosler: so now im trying make linux-dri-x86-64
icewaterman: hosler: i think that was not for you
hosler: icewaterman: i think were in the same boat
icewaterman: MrCooper: make: *** No rule to make target `linux-dri-x86'. Stop.
MrCooper: that's in the mesa toplevel directory?
icewaterman: MrCooper: i only downloaded the driver
icewaterman: which builds fine on x86_64
MrCooper: oh, I thought you were talking about mesa
icewaterman: just not for i386
hosler: mesage keeps erroring out: http://pastebin.ca/947522
hosler: mesa*
MrCooper: icewaterman: you need to set something like CC="gcc -m32" when running configure, but that is technically cross-compiling, and I don't thing the radeon driver supports that yet
simpsonc: icewaterman: Try adding CFLAGS="-m32" to configure.
simpsonc: That way, it doesn't trip the cross-comp configure.
icewaterman: simpsonc: good idea, i even have a cross-compiler installed, but during cross-compiling it complains about missing headerfiles even if i use --include-dir. so i will try -m32
icewaterman: simpsonc: unfortunately that doesnt work either
hosler: where are my mesa guys?
simpsonc: hosler: It's bloody 8 in the morning. Most of us are asleep.
hosler: oh yeah lol
MrCooper: icewaterman: how does it fail with -m32?
icewaterman: hm, even for cross-compiling it ignores the extra include dir i specified with ./configure --host=i686-unknown-linux-gnu --includedir=/usr/include
icewaterman: MrCooper: c compiler cannot create executeables
simpsonc: If you have a cross installed, shouldn't your tuple be i686-pc-linux-gnu?
icewaterman: config.log says it tries to compile a simple main(){return 1}; and fails
MrCooper: icewaterman: the problem for cross-compiling is that configure.ac uses macros not supported with cross-compiling
icewaterman: simpsonc: mine is i686-unknown-linux-gnu
simpsonc: icewaterman: That's, um, iffy.
MrCooper: icewaterman: is it the actual compilation that fails, or trying to run the resulting binary?
MrCooper: simpsonc: it's normal on Debian and derivatives at least
simpsonc: MrCooper: Most autoconf macros are cross-safe. I'd say it's more that Mesa is not tested on cross-compilers.
simpsonc: Ah. I haven't used Debian for development in a long time.
icewaterman: MrCooper: http://rafb.net/p/e0HNbq57.html
simpsonc: Huh, that's interesting.
icewaterman: MrCooper: fails when trying to link
simpsonc: Apparently r5xx doesn't set the has_tcl flag.
MrCooper: icewaterman: looks like your gcc installation is broken, it should pick up the 32 bit linker
icewaterman: MrCooper: i can compile 32-bit kernels
MrCooper: the kernel is special, in particular it doesn't link any libraries
icewaterman: MrCooper: i did take a look at binutils on that box and didnt find any 32bit linker at all
icewaterman: there is just /usr/bin/ld
hosler: building mesa through layman portage
icewaterman: wait, i'll "steal" the binaries elsewhere
icewaterman: because i think ubuntu hardy has already the 0.6.8 version in their ia32-libs package
glisse: hosler: you need a newer libdrm
icewaterman: anyway, is google-earth working properly with the 0.6.8 version? because i get strange and slow display while using google-earth
glisse: icewaterman: smooth line fallback
hosler: glisse: im building that too from git via layman portage
glisse: use driconf to diable that
glisse: disable
icewaterman: glisse: that doesnt help, maybe i should give you a screenshot
glisse: icewaterman: you disabled smoothline fallback ?
icewaterman: glisse: no, i thought it had to be enabled
icewaterman: and i though that enabling it was the fix
simpsonc: glisse: airlied's r5xx code is not setting has_tcl, is this correct?
icewaterman: glisse: http://madebyme.homeunix.org/users/matthias/test/googlearth.png thats how it looked like - works now that i disabled low impact fallback
hosler: ok so im gonna reboot again
glisse: simpsonc: in the ddx ?
glisse: or in mesa
simpsonc: In Mesa, tracing through the cmdbuf init.
simpsonc: chip_flags doesn't have TCL, so none of the TCL regs are being inited.
glisse: simpsonc: well don't worry about tcl for time being
simpsonc: Hmm, alright.
simpsonc: Right now I'm trying to find out where this damn null packet's being sent from.
glisse: simpsonc: in general when doing 3d driver you take the shortest way to have somethings on the screen
glisse: tcl can be done in cpu easily and fragprog is more advanced stuff
simpsonc: glisse: Okay. But right now my problem's much lower; for some reason a null packet is being emitted and causing DRM to (properly) choke.
glisse: so its better to do fragprog first and check that you got it working before tackling tcl, well that would be my plan and i like it when a plan come altogether ;)
simpsonc: Hmm. I like your plan and wish to subscribe to your newsletter. ( ^^)
glisse: A-Team have been a crucial part of my education :D
glisse: simpsonc: to track your null packet emission you can look into r300_cmdbuf.c
glisse: this is where we build cmd buffer before sending it to drm
glisse: i would put add a goold old printf debugging into r300EmitAtom which assert anytime you spot the wrong packet
hosler: glisse: ok if I use the fake chip id 0x791e, i get direct rendering: yes in glx info, but glxgears wont run. If i use my real chip id 0x791f then i dont get direct rendering.
glisse: hosler: glxgears says what ?
hosler: shoot let me go back to it, lol
hosler: brb
hosler: gliss: nevermind
hosler: glxgears is working, but only at 125 FPS
hosler: 177...
glisse: your eyes don't see much more than 30frame per second above you perception of reality is false, not even talking about the screen refresh rate
hosler: yeah
hosler: glisse: now im getting weird results with glxinfo
hosler: ill pastebin them to you
hosler: glisse: http://pastebin.ca/947594
hosler: whats RS690?
hosler: gliss: lol now glxgears doesnt work again. has same errors as glxinfo did
glisse: hosler: well nothings to worry about
glisse: rs690 is your chipset
glisse: x1250 or whatever is the comercial name
hosler: so i can play video games now?
hosler: i can play supertux with about 60 fps
hosler: sweet
hosler: shit, i gotta do homework
glisse: hosler: well give it a shoot but rs690 isn't exactly suited for lastest games
hosler: thanks guys i really appreciate it
agd5f: simpsonc: r5xx has tcl
tilman: agd5f: http://701bcd9cf4b776fd.paste.se/ this makes rendercheck a bit happier when doing a8-src-something_with_colors
simpsonc: agd5f: That's what I thought. At any rate, it's not the thing causing the gears to die.
tilman: agd5f: for r3xx-render, if that wasn't obvious :)
agd5f: tilman: thanks!
agd5f: I suppose I should push render to master
agd5f: for some more testing
tilman: thanks for implementing render accel :)
tilman: btw, CA doesn't work on my r420
agd5f: tilman: no problem :)
tilman: it's basically totally b0rked
agd5f: tilman: there may still be some issues. I haven't thoroughly tested with rendercheck yet
tilman: there are. the src_color/src_alpha/etc assignments need more touch ups i think
tilman: using R300_OUT_FMT_C_5_6_5 for a1r5g5b5 looks suspicious
agd5f: tilman: yeah, I don't think that will work
tilman: agd5f: there's a typo in r3xx_3d_regs.pdf, it seems. it says C_6_5_6 but i guess it should be 5_6_5
agd5f: yeah
agd5f: that's why I changed it
hosler: I just want you all to know that I can now play CounterStrike via Wine with no video lag using open source Radeon drivers.
agd5f: hosler: cool. got it working?
hosler: agd5f: yep
hosler: you guys can put Dell Inspiron 1521 as a working open source comp
hosler: now on to 3d desktop land
simpsonc: hosler: Nice.
rx__: airlied; yes w/your patch
simpsonc: rx__: Wait, what?
rx__: agd5f pushed experimental r5xx render support
rx__: but it's just a bunch of artifacts
simpsonc: Sounds about right.
rx__: black windows etc..
rx__: airlied's patch fixes the black windows
rx__: but still needs some fixin'
simpsonc: And don't even think about Composite. Still, exciting progress.
rx__: haha
rx__: i didn't dare try it :)
simpsonc: Stupid null packet still eludes me.
icewaterman: glisse: ok, seems i want to help debug the monitor offset issue
icewaterman: icewaterman: can i do that in windows?
icewaterman: or will i have to install fglrx in linux (because reading registers in windows would be preferred)
icewaterman: since ati driver is already installed there
mattst88: since there's been work done to replace all CARD{8,16,32} in xf86-video-intel with their stdint.h equivalents, would it be good to do the same with xf86-video-ati?
agd5f: mattst88: sure
mattst88: I've found my next project :)
icewaterman: hm, screen gets black when i logout from kde and use exa & accel_dfs
icewaterman: on x850 (PCIE)
icewaterman: xaa works fine.
edgecase: what chip is X1050? it's not in the man page
agd5f: edgecase: RV370
icewaterman: agd5f: do you know what chip is the newest with good 3d support by the radeon driver
agd5f: icewaterman: x800/x850
edgecase: any good online shops in canada, besides tigerdirect.ca?
agd5f: edgecase: not sure. does newegg ship to ca?
icewaterman: agd5f: ah, ok, then i was right to get one of those
OipOS: I don't think it does.
glisse: icewaterman: i dont know any tools under windows cant be of any help their
icewaterman: glisse: ok, in that case i'll have to use it on linux
math_b: agd5f: I'm testing your r3xx-render branch on a M24 (Mobility X600), the rendering appears to be correct, but "x11perf -aa10text" score is divided by 5.
glisse: simpsonc: did you try to plug in r300_cmdbuf to find out which state trigger this null packet ?
math_b: agd5f: I have oprofiled master vs. r3xx-render, I that might help...
agd5f: math_b: yeah, we were discussing that earlier. might perform better with newer xservers
agd5f: math_b: yeah definitely
math_b: agd5f: I'm on server-1.5 branch
agd5f: math_b: nevermind then :)
agd5f: math_b: what does oprofile show?
math_b: agd5f: that libexa sucks
math_b: 21% spent in ExaOffscreenMarkUsed and 8.5% in exaPixmapIsOffscreen
math_b: Will paste the full results
icewaterman: glisse: what registers should i look for?
icewaterman: radeontool regs shows some, which shall i compare to debug the resolution difference between fglrx and radeon?
math_b: r3xx-render: http://pastebin.com/m14f99d16 vs master: http://pastebin.com/d66d28e7f
airlied: agd5f: I think the VAP setup needs "tuning" per card..
airlied: agd5f: which might explain the rv515 textured video and rv530 render..
agd5f: airlied: "tuning?"
edgecase: yeah newegg is fail ship to canada
edgecase: ncix is ok
airlied: agd5f: the NUM_* bits in the control regs
agd5f: ah, yeah numclrs and such
airlied: agd5f: yup those..
agd5f: there's an algorithm in the r5xx guide
agd5f: our defaults are kinda low
airlied: I think they might be high for the low end and mobile chips :)
rx__: airlied; did you witness what i saw w/m56?
agd5f: airlied: or that :)
glisse: icewaterman: i gived register name earlier
glisse: icewaterman: CRTC_H_SYNC_STRT_WID
glisse: first 3 bits might looks different btw fglrx & radeon
icewaterman: glisse: ah, ok, didnt find the register with radeon driver though
airlied: rx__: yes my M56 did the same thing.
airlied: rx__: trying to track it down, will bring into office today.
rx__: oh alright
icewaterman: glisse: http://rafb.net/p/0YlHdS26.html these are the only ones i've got
agd5f: airlied: as osiris_ has seen, rs690 only works properly after running a 3D app
airlied: agd5f: interesting.. we must be missing some reg..
agd5f: yeah
glisse: icewaterman: radeon likely use a different name checkout from the offset
glisse: agd5f: so for the tex instruction there is no flag for telling if we want coord from const or from temp ?
icewaterman: glisse: ok, i'll do some register snapshotting for different resolutions.
agd5f: glisse: only seems to support temps on r3xx at least. r5xx seems to support both
glisse: icewaterman: well resolution where its the more obvious should be enough
glisse: agd5f: this sounds strange as i am pretty sure we got program which should have exhibit bug if this were the case
glisse: would need a dump of fglrx to check again if we really see this bit set but i believe if we did put it in first time its because we did see it
agd5f: icewaterman: looks like you are using an old radeontool. you want: http://cgit.freedesktop.org/~airlied/radeontool/
agd5f: glisse: it's possible.
icewaterman: agd5f: ok
icewaterman: agd5f: i used the one that came with the distro
agd5f: icewaterman: radeontool regmatch '*'
icewaterman: agd5f: where can i check the sources out?
icewaterman: ok, dont bother i'll copy the few files manually
agd5f: icewaterman: git clone git://people.freedesktop.org/~airlied/radeontool
FurnaceBoy: anyone know how to get card temp from radeonhd driver (linux), X1650 Pro
agd5f: FurnaceBoy: not supported ATM
FurnaceBoy: ok thanks
FurnaceBoy: related question. anyone ever found a replacement fan for cards like that or similar? :)
FurnaceBoy: having multiple units fail after 6 weeks
FurnaceBoy: cheap chinese fans, i guess
agd5f: FurnaceBoy: doublesided tape and a case fan?
FurnaceBoy: agd5f: yes I have done something like this. just wondering if there's a source for these funny little fans
FurnaceBoy: nobody seems to be able to locate them
icewaterman: agd5f: i hope this message is not going to be a problem: it prints a lot of registers but also 6 times: Radeon control memory not found.
icewaterman: oh, btw, that how can one read the temperature from the card?
icewaterman: my card has a temperature sensor (at least windows driver can read it)
glisse: icewaterman: through board sensor likely using some i2c stuff
icewaterman: glisse: do in need some extra module for that?
icewaterman: i mean besides the lm-sensors stuff
icewaterman: but anyway, one thing at a time, first the register dumps
glisse: icewaterman: well you need that the kernel module expose the i2c bus if this is an i2c bus
agd5f: icewaterman: it's controlled via i2c over some gpio line
icewaterman: agd5f: hm, ok, i'll try that later
agd5f: icewaterman: that hard part will finding what pins are used
FurnaceBoy: Catalyst shows temp.
glisse: agd5f: s/hard/fun/ ;)
icewaterman: glisse: just before i now install the fglrx driver: is it normal, that the register contents doesnt change at all during resolution switch?
icewaterman: because for 1280x1024 1024x768 800x600 and 640x480 the register dump is always the same
icewaterman: CRTC_H_SYNC_STRT_WID (0204) 0x00000000 <-- looks suspicious
icewaterman: this is the entire output http://rafb.net/p/MobqR690.html
icewaterman: most of the registers are either all 0 or 1 with very few exceptions
agd5f: icewaterman: that dump is bogus
icewaterman: agd5f: Radeon control memory not found.
icewaterman: thats what it says at the beginning
agd5f: maybe it can't mmap the mmio range? I don't recall what the message means.
icewaterman: agd5f: maybe this is due to pax
math_b: agd5f: r3xx-render cause drm errors at xserver startup:
math_b: [drm:r300_emit_carefully_checked_packet0] *ERROR* Offset failed range check (reg=4540 sz=1)
math_b: [drm:r300_do_cp_cmdbuf] *ERROR* r300_emit_packet0 failed
icewaterman: agd5f: does radeontool work on amd64 at all?
agd5f: icewaterman: yeah
icewaterman: agd5f: ok, i'll boot a vanilla kernel
icewaterman: maybe it gets better then
icewaterman: need to compile one first though
agd5f: edgecase: JB recommends NCIX for ca purchases: www.ncix.com
edgecase: well i had an issue with their $1200 X800's
agd5f: edgecase: heh... I guess they are getting to be collector's items ;)
icewaterman: agd5f: grsecurity has some options for restricting access to /dev/mem
agd5f: edgecase: ebay maybe?
agd5f: icewaterman: ah
icewaterman: edgecase: i got an x850xt on ebay for approx. 20$
arekm: ohh, new commits. /me updating ati to git version
arekm: crap, branch 8)
agd5f: arekm: branches are easy :)
airlied: arekm: it'll be in master tomorrow hopefully :)
arekm: agd5f: branches indicate "not yet ready" stuff
agd5f: arekm: indeed, fun to play with though :)
arekm: anything cool from r300 user point of view? then I'll gladly test branch :)
airlied: arekm: render accel.
airlied: time for office..
icewaterman: ok, compiling vanilla kernel now. this way fglrx wont screw up my main kernel as well :)
arekm: so what actually render accel gives me? nicer screen rotation, something else?
agd5f: arekm: fast desktop with exa, translucent windows, etc.
rx__: i guess the x800xl i've got is a keeper :)
icewaterman: rx__: x800xls are cool, because they consume less power than the XT :)
arekm: agd5f: fast compiz, too? 8)
icewaterman: i was originally planning to get an x700 but i didnt manage to get one cheap
rx__: well i got lucky
rx__: i got a x800gto and was able to softmod it
edgecase: I'm searching ebay, there are some deals
agd5f: arekm: no compiz uses 3D
edgecase: i'm looking for low profile PCI(-e)
libv: edgecase: dell
edgecase: some x800 are LP, as are 3460, but those don't work yet?
edgecase: yeah some guys are selling gx270's case only
agd5f: arekm: fast xcompmgr or various other compositers
edgecase: but local shop I *just* found they have LP cases
edgecase: $55
libv: edgecase: dell sells the low profile radeons seperately
libv: edgecase: they are kind of steep though
icewaterman: btw. when i logout from kde, and am using exa, my screen turns black
edgecase: oh i have about 18 X300's with LP brackets, from dells
edgecase: $0.50 each
icewaterman: edgecase: 50ct=
edgecase: a local shop has hundreds of older video cards, from r128 thru X300's (what i bought all of
edgecase: yeah fitycent
icewaterman: edgecase: thats cool
edgecase: i got 2 with S-video/component out
icewaterman: if only i got one that cheap :)
edgecase: and i got cables now too
edgecase: but i want something with Atombios to try booting up with TV for cmos settings
arekm: whoah, a lot of triangles and boxes
edgecase: anyone wants to setup a Radon lab, i can put 1 of each of early product line in a box and mail it
arekm: icons/graphics not rendered properly. text (in kde konsole) rendered nicely
arekm: agd5f: http://carme.pld-linux.org/~arekm/a.png
icewaterman: agd5f: hm, same output, same error
icewaterman: so it wasnt pax, i now run a vanilla kernel
icewaterman: oh, btw, i know where some of the messages result from
icewaterman: it tries to read AGP_BASE and some other agp stuff which is not present in pci-e system
icewaterman: so the messages are just fine
icewaterman: register content didnt change though
agd5f: arekm: hmmm... I just rebooted and now my desktop looks like that. there must have been some state from something I tried that made it work
agd5f: previously
icewaterman: agd5f: when i run radeontool with --debug, it segfault
icewaterman: ss
agd5f: icewaterman: strange
icewaterman: agd5f: and i know why that is
icewaterman: if(debug)
icewaterman: fprintf(stderr,"mmap returned %d\n",(int)device_mem);
icewaterman: fatal("mmap error \n");
agd5f: ah
icewaterman: radeontool.c:128: warning: cast from pointer to integer of different size
icewaterman: probably and 32/64bit issue
icewaterman: are you sure this ran on amd64 lately?
agd5f: icewaterman: works fine here
arekm: sleeps
icewaterman: agd5f: is it a 64bit binary?
icewaterman: maybe you are using 32bit radeontool
agd5f: radeontool: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), for GNU/Linux 2.6.0, dynamically linked
icewaterman: hmm
icewaterman: these are the only values that are either not all 1 or all 0
icewaterman: http://rafb.net/p/icGwq534.html
icewaterman: this is the radeon driver only of course, havent tried fglrx yet
simpsonc: Ahoy, gentlemen.
simpsonc: glisse: Somebody near r300_emit isn't filling out the cmd_type for a packet, and it's dying with an 'unknown cmd_type'-like error.
simpsonc: The reason I think it's a null packet is that the unknown cmd_type is 0x0.
simpsonc: At any rate, it's frustrating because GDB can't reach in there without causing insta-hangs.
icewaterman: hm, agd5f how does you radeontool output look like?
icewaterman: because i'd really like to know why my registers are almost entirely not displayed
agd5f: looks fine
icewaterman: agd5f: even though almost all registers are either f or 0?
airlied: simpsonc: its most likely the fpi emits like I said..
agd5f: icewaterman: your looks bogus
airlied: simpsonc: look at what I changed in my patch to mesa.
icewaterman: agd5f: dunno why it looks that way, but i am using vanilla kernel now, no special options
agd5f: icewaterman: I dunno. very strange
simpsonc: airlied: Been looking. I can't find any glaring errors. I'm fairly certain that r300_cmdbuf has no problems.
simpsonc: And to be honest I'm still unclear on the mechanics of most of r300_emit.
airlied: ah I see a bug in my r300_emit.h patch
airlied: but I doubt thats it.
agd5f: arekm: try using textured video. that should "fix" render
mike90: Hi everyone, I'm currently having some issues running 3D /OpenGL on X, I'm running an ATI 9800 and have the Catalyst drivers installed and I'm getting this error "AIGLX: 3D driver claims to not support visual". I'm able to get Beryl running but it's not displaying any changes. I'm running Xorg 7.1.1. Any helps would be greatly appreciated.
airlied: mike90: #ati..
mike90: ah okay, I am using the "radeon" drive tho but I'll check #ati non the less
airlied: mike90: why did you mention catalyst?
mike90: Sorry my mistake then
simpsonc: airlied: Time for class again. I'll look into r300_emit again later.
airlied: agd5f: woot textured video fixes it on M56GL
airlied: now to dig..
agd5f: airlied: interesting
icewaterman: could it be my radeon getting hotter on linux than on windows?
icewaterman: because now it regularly crashes after some time in 3d games
agd5f: icewaterman: could be. could also be our 3D driver isn't as stable as the windows driver
agd5f: ;)
icewaterman: agd5f: well could be but why crash only after a while?
airlied: agd5f: I think it survives a reboot..
agd5f: airlied: how about a full shutdown?
agd5f: so strange
icewaterman: ok, it is late, gtg to bed
airlied: agd5f: trying poweroff now.
airlied: agd5f: nope.. shutdown goes back to triangles.. this is wierd..
agd5f: airlied: survices a reboot here too. just not a power off
agd5f: survives even
edgecase: what about front panel reset button?
airlied: edgecase: my laptop doesn't have one :)
edgecase: ah. well things that survive reset button are either meant to be CMOS, or bad hardware design
airlied: edgecase: RAM often survives it
airlied: edgecase: RAM doesn't lose all its contents instantly.
edgecase: yeah, reset vector clears it out tho
edgecase: i was thinking more about registers
agd5f: edgecase: same difference.
edgecase: well #RESET should always clear registers, except for CMOS/pwr mgmt stuff
edgecase: i've been wondering about radeon reset, in say a kernel modesetting driver, is it possible to *always* restore GPU to know good state, without system #RESET ?
airlied: edgecase: in theory we can do it now, we just never managed to get it right on all cards.
edgecase: i've seen things on windows, nvidia/ati cards, that i suspect was a full reset
airlied: edgecase: ATI have a VPU recover on windows ..
airlied: which reboots at least the acceleration engine..
edgecase: yeah, desktop freezes, screen goes DMPI off, then desktop redraws
Lotek: i have a hd2600 with debian etch I cant get the vesafb or vgafb to work, on vga=ask i only get 80x25 i have seen this work with lilo but i would like to use grub
carldani: Hi.
carldani: I'm probably a bit late to notice the r3xx 3D doc release, but I'm very happy about it
carldani: is there a way to find out why graphics performance decreases when I enable DRI on my X550?
carldani: AFAIK enabling DRI should increase performance a lot.
agd5f: carldani: in what sense does it decrease?
carldani: agd5f: it's a game in Wine (star trek bridge commander) and the intro video gives me something like 2 fps without dri and 1 fps with dri on my amd64 box with the X550
carldani: agd5f: the video is smooth on a 400 mhz machine with an obsolete graphics card under windows
carldani: agd5f: with dri, the video shows one frame, switches to black, shows another frame, switches to black again, etc.
agd5f: maybe something in wine?
carldani: agd5f: without dri, the video is still slow, but there are no intermittent black periods
carldani: it could be something in wine, but the black screen between frames depends on dri on/off and not on any wine config
airlied: carldani: that just means the GPU rendering vs the CPU rendering most likely.
carldani: would oprofile help finding the bottleneck or do waits for the GPU not show up in any profile?
airlied: carldani: so going from 2 to 1 fps isn't really performance decrease.. you probably need to use oprofile.
airlied: or sysprof
mattst88: off hand, where are CARD{8,16,32} defined?
airlied: mattst88: xMD.H
airlied: X,md.h
airlied: arrgg..
airlied: Xmd.h I think
mattst88: yes, that's right. thanks
carldani: hm. now I just have to find an oprofile version that doesn't crash.
edgecase: pci-express has 3 inherent reset functions, Hot reset is signaled, can leave powermgnt and error reporting registers intact
edgecase: A good datasheet would say if there are any Sticky Registers that survive hot reset
edgecase: Linux PCI-express AER driver/framework exists... some radeon kernel driver should handle the device errors it generates
airlied: edgecase: we rarely get those types of errors..
airlied: edgecase: mostly radeon locks up internally not on the bus..
edgecase: sure, it's a different entry path, but the recovery routine should mostly be in common
edgecase: which is to say, radeon driver could initiate pci-e device Hot reset (new function?), and also respond to spontaneous resets caused by pci-e
edgecase: pci-e reset would give "the hammer" to the card, in case other reset methods fail
edgecase: need an Alt-Sysrq function for that
airlied: oh this just gets wierder and wierder..
airlied: if I play one frame of a movie, it fixes some parts..
airlied: and for every frame I play more stuff gets fixed.
airlied: 10 frames fixes all of it, hmm I remember seeing a 10 somewhere in the RS setup
airlied: okay somewhere in the VAP..
airlied: if I disable the vap for textured video it no longer fixes it.