ComBatXL: hello everybody! i have the radeon x1300 and use a dualscreen setup. i used the fglrx driver before and everything worked fine. since fglrx is no longer supported i had to switch to radeon/radeonhd . unfortunately i have a nerving mouse cursor bug:
ComBatXL: there are areas on the screen where the mouse cursor converts to a little box or gets otherwise stuck
ComBatXL: does anyone have an idea how i could solve this?
yangman: ComBatXL: http://bugs.freedesktop.org/show_bug.cgi?id=19215
nanonyme: (This is btw why all professionals evaluate changes before choosing to upgrade any production systems. You might find out some upgrade sucks :p)
ComBatXL: thanks alot yangman i will subscribe to this bug :)
airlied: damn R clamp gives dierent issue on my r5xx
dileX_: airlied: looks funny here with 20a68122439f1efebed5226ce3ca381f7be36303, no fonts in console (rxvt, konsole), vlc-video has green background. thought I had to update my mesa/mesa first
airlied: dileX_: I just psuhed a new cs3 just goint to push master
dileX: airlied: thx. after compilation of mesa/mesa (approx. ca. 25-30min)
airlied: okay I pushed what I think will fi it to master
glisse: airlied: yeah i missed the evict flag
dileX: airlied: mesa/mesa is breaking in obj-i486-linux-gnu/swx11+glu-static/src/gallium/winsys/xlib
airlied: glisse: still no ideas why the agp cards get the black line corrupt apart from AGP being crapp.
airlied: I think using PCIGART or that VRAM->RAM transers might be the best answer
glisse: i myself beaten by ttm ununderstable move code
airlied: glisse: I've been trying to think could it be made any more understandable :)
airlied: but VRAM->RAM via TT is a messy job
glisse: internal move test works but as soon i do my bo move through ttm, ttm pretty much confuse everythings
airlied: I spent ages making my tree get all the paths right
airlied: I don't think newttm got any of the fixes
dileX: merged latest commits from master into radeon-rewrite
trurl: /msg nickserv set hidemail on
glisse: agd5f: on r420 this is atom right ?
glisse: but it can use combios functions ?
max_r: noticed strange messages in dmesg: http://pastebin.ca/1401774 using r6xx with drm from ~agd5f
airlied: glisse: not atom only
airlied: no atom only even.
airlied: but we use legacy modesetting mostly
glisse: airlied: so for posting it's atom bios right ?
airlied: my code just uses if atom bios to decide
airlied: its not really chip specifc but BIOS specific
glisse: airlied: is there a quick way to know where in the kernel userspace is stuck ?
glisse: ie entry point
airlied: echo t > /proc/sysrq-trigger
airlied: if the process is stucks and not looping
glisse: airlied: thanx, kernel is full of nice info :)
airlied: agd5f: I think all of this R clamping issue might also have something to do with the Z/W routing fix from way back
spstarr: glisse: ping
spstarr: what is drm-next-radeon-backup* ?
spstarr: you have so many branches ;)
glisse: spstarr: test backup2
glisse: i am going to delete drm-next-radeon
spstarr: glisse: building your kernel now...
spstarr: and I just woke up :)
glisse: and replace it with cleaned up version
spstarr: which one will checkout from?
glisse: which should have everythings working
glisse: backup2 has all the lastest working code
spstarr: oh so its a lot more changes in backup2
spstarr: lemme compile and test s/r, XRender, XComposite
spstarr: glisse: will tell you results
spstarr: thats lots of changes in -next-radeon..
glisse: well cleanup mostly
spstarr: i see things moved around, ya
mikkoc: airlied: this commit breaks everything here, especially kde apps.. but gtk too
mikkoc: screenshot: http://i44.tinypic.com/30kc4qv.png
spstarr: time to install
spstarr: glisse: you plan to rebase against 184.108.40.206?
nanonyme: Happy weekend to everyone. ^^
ech0s7: to try 3D on rv620, i have to recompile mesa (r6xx branch) ?
max_r: ech0s7: any luck with 3d on rv620?
ech0s7: max_r: i don't know
ech0s7: i would try it
ech0s7: but i don't know how
ech0s7: i have to compile mesa from git branch rv6xx ?
max_r: from mesa branch called r6xx-r7xx-support
max_r: and you will need new libdrm, drm headers and drm modules from ~agd5f/drm
max_r: r6xx-r7xx-3d branch
max_r: what distro are you using?
kdekorte: max_r, 3d doesn't do a whole lot right now
max_r: kdekorte: it crashes for me on rv635 :)
max_r: kdekorte: I was interested will it work for ech0s7, to see if did something wrong
max_r: kdekorte: does it work for you?
ech0s7: max_r: archlinux i'm using
ech0s7: i have to compile *ALL* mesa ?
ech0s7: it take a much of time
max_r: actually compiling mesa with needed drivers (use flags here on gentoo) takes 1 minute 18 seconds
max_r: it compiles swrast radeon and r600 dri drivers
spstarr: glisse: fail
spstarr: glisse: X doesn't start up at all
spstarr: it gets stuck in tty but DDX doesn't start
max_r: ech0s7: obviosly you can use some configure options for mesa to do the same thing
max_r: ech0s7: here it calls ./configure --prefix=/usr --build=i686-pc-linux-gnu --host=i686-pc-linux-gnu --mandir=/usr/share/man --infodir=/usr/share/info --datadir=/usr/share --sysconfdir=/etc --localstatedir=/var/lib --with-driver=dri --disable-glut --without-demos --disable-debug --disable-glw --disable-motif --enable-glx-tls --disable-xcb --with-dri-drivers=,swrast,radeon,r600 --disable-gallium --enable-asm --enable-asm
nanonyme: max_r: Probably most of which are excess and duplicate default behaviour? :)
kdekorte: max_r, all it does it crash my machine
max_r: nanonyme: yes, but it it faster to copy all than to find out what is default and what is not
max_r: kdekorte: do you use r6xx or r7xx?
kdekorte: max_r r635 (radeon 3650)
max_r: kdekorte: amd64 or x86? and what kernel version?
max_r: kdekorte: same here
kdekorte: on Fedora 11.. so .29 kernel
max_r: kdekorte: does it lockup whole os or glxgears just crash?
kdekorte: I hear that .27 or .28 are the only ones that have a shot of working
kdekorte: whole os
max_r: kdekorte: for me on x86 and same kernel/card glxgears just crash
max_r: yesterday there was Zajec here, also on amd64 and he also had lockup
kdekorte: the first release, that leaked memory just seg faulted... but patches since then, crash the machine
max_r: kdekorte: and how are you using drm with .29 kernel?
kdekorte: Zajec and I have similar setups
kdekorte: it would compile and install and I had xv working, so drm was working.. I think there were some bugs in the memory free code
max_r: kdekorte: are you using drm from mesa/drm or from ~agd5f/drm?
spstarr: oh i need a new DDX from git?
kdekorte: I was using agd5f's
ech0s7: max_r: i'm tring
max_r: kdekorte: what patches have you used to make it work with .29?
kdekorte: I didn't do any
ech0s7: i need only of this ?
max_r: kdekorte: and it loads fine to .29 kernel???
kdekorte: max_r, well it seemed to... but I have taken it all out now went back to stock F11 stack
max_r: ech0s7: you will also need http://cgit.freedesktop.org/~agd5f/drm/?h=r6xx-r7xx-3d
max_r: kdekorte: it is very strange because for me it produces warning about missing init_mm symbol at compilation time
ech0s7: max_r: of r6xx-r7xx-3d branch or master branch ?
ech0s7: ok have seen
max_r: ech0s: r6xx-r7xx-3d branch, and you will need to install it befor mesa
ech0s7: r6xx branch
kdekorte: max_r, yeah I heard of that happening.. I just didn't run into it... like I said the r6xx 3d is so buggy right now and does so little that unless you plan on submitting patches it is not worth it right now
ech0s7: so now i try
kdekorte: I could only get one demo to sort of work..
max_r: kdekorte: what demo?
kdekorte: all the rest had massive screen corruption or seg faulted and then when it started locking the OS I gave up
max_r: winpos works for me too
max_r: sort of
kdekorte: like I said.. it is pretty limited
kdekorte: The developers know they have work to do and when they are ready for more people to test, I'll be there, but for now I'm gonna sit back and just lurk about it
spstarr: glisse: i have pulled new DDX from you, does this fix it from locking up?
max_r: kdekorte: and what are their current priorities, radeon-rewrite/kms/dri2/... or r6xx-r7xx-3d?
kdekorte: max_r, I'm not sure... I think it depends on the developer.. I do think that r6xx3d is after the radeon-rewrite is done
kdekorte: or they will be merged together, but I am just guessing..
chithead: max_r: both are being worked on in parallel by different developers. also see phoronix http://www.phoronix.com/forums/showpost.php?p=71022&postcount=17
max_r: chithead: ya I saw it, I honestly don't like the variant with merging r6xx-r7xx-support to radeon-rewrite first
max_r: previous plan with releasing non-kms/dri2/... 3d for r6xx looked better
nanonyme: max_r: I kinda do, rewrite-r600 would be actually useful.
max_r: is there any way to use some kind of gui debugger (like one in eclipse) to debug glxgears's crash? Or it is now more infrastructured bug than some one-liner?
max_r: nanonyme: it will force us to test another bunch of stuff, which is not needed right away
nanonyme: DRI2 kinda being the main achievement with the open drivers towards making things like Compiz Just Work (tm).
kdekorte: radeon-rewrite is probably needed.. but I'm wondering why they just don't go straight to gallium.. unless there is a learning curve with the hardware there
max_r: nanonyme: things like compiz could wait, tuxracer and google earth couldn't :)
nanonyme: kdekorte: bridgman told me some good reasons on the channel, I can relay them when I finish my train trip.
nanonyme: Cell phone sucks for explaining.
kdekorte: nanonyme, sounds good, just curious as to the logic, but not critical
kdekorte: nanonyme, I run my whole house off of a sprint broadband card... so I get slowness
max_r: kdekorte: afair initial logic was to provide non-gallium, non-kms 3d for distributions, that will not include such experimental stuff in gallium in their next release
nanonyme: If you're impatient, could check channel logs. He said it day or two ago iirc.
kdekorte: max_r, oh ok.. that makes sense
kdekorte: I was just wondering cause the nouveau people are just going straight to gallium, but I guess they have a further out target for 3d support
kdekorte: that is good enough for me
max_r: nouveau people have good closed-source driver behind them in case of delay or some other problems with oss drivers
kdekorte: max_r, yeah I've had such mixed experience with fglrx... one release works great.. the next total garbage
kdekorte: I finally banned it from my machine
max_r: kdekorte: same thing here, with xv support I can leave without fglrx
kdekorte: actually, I develop gnome-mplayer, an even decent x11 support is good enough for me to test, but having a working xv has been helpful
max_r: kdekorte: btw, are you using xorg-server 1.6? Does it matter for xf86-video-ati and r6xx 3d?
kdekorte: max_r yes I am using 1.6, and I had trouble compiling the mesa stack on my Fedora 10 (1.5) machine
kdekorte: I;m not sure if it is a hard requirement or not
max_r: kdekorte: strange, 1.5.3 here, but no problems compiling mesa.
kdekorte: I think it might have been with the drm stuff... be while since I tried
bridgman: kdecorte; the main reason for going with "classic mesa" first was to provide a solution for users running distros without kms & memory management
bridgman: gallium3d is implemented over dri2/mm; could be changed to work over current environment but nobody thinks that's a good use of time
bridgman: a lot of the work is just getting the programming sequences for the chip correct, and those can move easily from classic mesa to gallium3d
bridgman: radeon-rewrite (bufmgr, cs, memory management support) happened a bit more quickly than we expected so the short term focus is porting to a copy of radeon-rewrite rather than staying with the older code
bridgman: that wasn't part of the original plan ;)
max_r: bridgman: so there will be no non-kms/dri2/... version of r600 3d?
bridgman: anyways, even though mm is showing up in the most aggressive distros now (eg Fedora) it's probably going to be a year or so before it ships in all the major distros, so we need a non-mm 3d solution for as much as a year
bridgman: max_r; the whole poitn of doing classic mesa is to make a non-kms/dri2/... r600 3d
bridgman: if it weren't for that we would have gone straight to gallium3d probably
bridgman: we want something that can go in distros "real soon now"
max_r: and real soon is weeks, or months?
bridgman: probably right in that "small number of months or larger number of weeks" zone ;)
glisse: spstarr: i pushed a new cleaned up tree
glisse: i am testing it accross my gpu
glisse: so far seems to work
spstarr: glisse: so which branch? ddx and drm bits?
glisse: drm-next-radeon but it's a new branch
glisse: ie rebase or pull wont work
bridgman: moving to a radeon-rewrite base and a new mesa-to-drm API will probably end up costing a month, and there's probably another month of work we missed in the initial planning, so if I had to guess i would say some time in June before we have parity with 5xx
max_r: bridgman: will it be posted in big chunks like initial mesa drop, or it will go faster as xf86-video-ati recently?
spstarr: hullo bridgman
spstarr: glisse: i'll rm and clone
bridgman: it depends a bit on whether other devs are able to pile on and help; there's just so much different work going on in the open source stack right now that every dev is working on something different
bridgman: ... and they're probably working on the right stuff
phoenix64: are there any estimations for GLSL on r300 btw? :D
spstarr: shit thats a lotof changes!
spstarr: -30 lines +31926
spstarr: glisse: how do you resolve conflicts?
spstarr: or i have to blow away tree
spstarr: bows directory
bridgman: phoenix64; in theory glsl comes for free once gallium3d is running
bridgman: in practice it won't be that easy of course, but it should be a good start
spstarr: glisse: new DDX needed?
glisse: spstarr: no you cna do that:
phoenix64: hm, so the shader format on the GPU is known well enough?
glisse: git rebase --onto oring/drm-next-radeon drm-next-radeon drm-next-radeon
spstarr: oh with rebase
bridgman: phoenix64; yep, already being used for Xv and EXA, and it's been in public for a year or so
spstarr: glisse: so same DDX you have?
spstarr: ok you rebased with airlied's DDX
spstarr: glisse: im confused, I thought you had done the TTM work.. what is Thomas's stuff?
bridgman: glisse is integrating thomas's stuff into radeon tree, and probably changing it in the process
spstarr: I see
glisse: spstarr: now it's mostly mergeable with drm-next
spstarr: so what changes vs what I tested before?
glisse: likely some more things to axe before sending to lkml
glisse: spstarr: it's pretty much the same code as drm-next-radeon-backup2
glisse: or as previous drm-next-radeon
spstarr: you made additional fixes? as i could not start X before
osiris__: glisse: could you add an interface for checking if bo is idle? it's crucial to run OQ in decent speed
glisse: osiris__: i have to finish testing, than do agp resume and i will do that
osiris__: glisse: cool :)
glisse: osiris__: it's just few lines of code
spstarr: glisse: building
glisse: ioctl is already their
spstarr: glisse: but im concerned it will not start X
glisse: in radeon_gem.c
b0le_: I also couldn't start X with backup2
spstarr: b0le_: hmmm, thats not good
glisse: b0le_: i think a fix was missing from backup2
glisse: as i was cleaning the tree i did few small fixes
dileX: so drm-next-radeon (commit #83421dfc1fb5d92d2d8d18b054d469c7ee5dfa90) is latest
glisse: dileX: yeah
spstarr: glisse: compiling..
spstarr: glisse: i will let you know if i cant start X
osiris__: glisse: so the corruption should be fixed in your current tree?
glisse: osiris__: i think so
osiris__: glisse: great, will check it out
glisse: at least so far i didn't see any
spstarr: glisse: /root/rpmbuild/RPMS/i386/kernel-2.6.29-8.i386.rpm
glisse: but i quickly test on each card, gears+quake3+firefox running side by side
glisse: oh and compiz
glisse: suspend resume and i go to next gpu
spstarr: bridgman: i have an updated resume coming once I go to DBM services on the 30th+ 'career transition' services my ex-company is providing me
spstarr: you can toss that one ;)
spstarr: rebuilds DDX also
spstarr: heh virtualbox just tripped an oops
spstarr: [ 9698.531317] BUG: unable to handle kernel NULL pointer dereference at 00000004
spstarr: [ 9698.531332] IP: [
spstarr: prepares to reboot
bridgman: spstarr; ok thanks
dileX: glisse: kernel looks good
glisse: dileX: why it doesn't work ?
b0le_: glisse: works here
spstarr: glisse: works here
spstarr: im in X
spstarr: glisse: I should avoid suspend to ram?
glisse: also side note suspend/resume won't work if fbcon loaded
spstarr: turns on XRender
glisse: and won't work on agp
glisse: yeah i need to update my agp box
dileX: glisse: have to build libdrm, mesa and ati-driver 1st. kernel seems to be OK on first sight
spstarr: ok i will avoid s/r until you have that working
spstarr: testing XRender + VT switch
spstarr: XRender works
spstarr: VT switches
spstarr: tries XComposite
glisse: spstarr: you are trying to put some suspens in this testing ;)
spstarr: glisse: regression testing
spstarr: KWin turns on XComposite but fails miserably.. now to compiz-gtk
glisse: hhhm seems i busted 3d on r3xx/r4xx
spstarr: now in compiz-gtk corruption
spstarr: glisse: i have text glyphs corruption
spstarr: the letter 'p' is blank
spstarr: some of my letters in xchat just went blank now they came back(?)
spstarr: glisse: VT switching with compiz enabled i have missing letters in xchat
spstarr: but it happens w/o vt switch
glisse: spstarr: likely normal i am doing somethings wrong in 3d on r3xx/r4xx
glisse: it's cliprect stuff
glisse: strange i though i did have mesa working
spstarr: runs glxgears
spstarr: that works
spstarr: but what is 'IRQ's not enabled, falling back to busy waits: 2 0'
spstarr: we're not using IRQ but polling instead?
glisse: that error message is not exactly accurate
glisse: in kms world
spstarr: glisse: using cube mode with glxgears glxgears freezes for a few milliseconds
spstarr: now it's not
glisse: how much vram you got already ?
spstarr: roughly even though not accurate
spstarr: 174 frames in 5.0 seconds = 34.696 FPS
spstarr: 141 frames in 5.3 seconds = 26.670 FPS
spstarr: since we dont use this for real info
spstarr: but it showed it stalled
spstarr: 64 MB VRAM
glisse: resolution ?
spstarr: (II) RADEON(0): Front buffer size: 5808K
spstarr: (II) RADEON(0): Remaining VRAM size (used for pixmaps): 55600K
spstarr: thats all you get :)
spstarr: blame IBM for putting too little ram
glisse: well it's big desktop :) but m10 should handle it fines
spstarr: it should, yes
glisse: i think until we actually optimize ttm some more you will see such regression
spstarr: you mean this isn't optimized yet? :) wow
spstarr: well, i dont care about optmization yet, if things are working this is good
glisse: not at all right now we are moving way to much megs of data around
spstarr: minor text glpth corruption is is more annoying
spstarr: I am not seeing any other kind of corruption yet
spstarr: I still have offscreen pixmap corruption when maximizing/minimizing xchat
spstarr: but thats still EXA's fault =)
glisse: the glyph corruption shouldn't happen
glisse: spstarr: would be nice if you could run radeon_bo_test in drm/test folder
spstarr: er libdrm? or kernel bits
glisse: make radeon_bo_test
spstarr: im using rawhide libdrm w/o git
glisse: in the folder will build the exe
spstarr: one moment checking master out
glisse: it's in modesetting-gem branch only i think
spstarr: will get
spstarr: glisse: what tests does it do?
spstarr: lots of blitting etc?
spstarr: getting modesetting-gem
spstarr: glisse: now im getting corruption
spstarr: some _____ lines
spstarr: missing text, garbled text in firefox URL:: line
spstarr: glisse: screenshot coming now
spstarr: glisse: http://www.sh0n.net/spstarr/ttmcorrupt.png
spstarr: notice the 'p's are all missing as in s'p'starr in xchat screen ;)
spstarr: glisse: i cant switch to modesetting-gem?
spstarr: got it
spstarr: glisse: I am seeing similar corruption like airlied's bits
Julius2: I'm trying to get X working
spstarr: it is less right now however
soreau: Julius2: Which card model do you have?
Julius2: how do I check?
Julius2: I'm a newbie
soreau: lspci|grep VGA
spstarr: now im getting more corruption in text glypths
Julius2: Mobility Radeon HD 3650
soreau: spstarr: FWIW, I get the same thing here, much worse in kde than gnome though
spstarr: soreau: with newttm?
soreau: spstarr: Oh sorry, no
soreau: just whatever rawhide updates give
soreau: Julius2: You should be able to at least start X, but the radeon drivers don't have 3D working for that card yet
soreau: Julius2: Which distro are you using there?
spstarr: glisse: can't build test that way.. sec building it with autoconf
Julius2: xorg version is 1.6.1
Julius2: I asked for help in ##linux before this, and then sent me to #xorg
Julius2: and after fixing a few keyboard and mouse-related problems, they didn't know so they sent me here :P
Julius2: when I run X -config xorg.conf.new
Julius2: I get a black screen
Julius2: no mouse pointer or anything
Julius2: that is xorg.0.log
soreau: takes a look
Julius2: drmOpenDevice: node name is /dev/dri/card0
Julius2: drmOpenDevice: open result is -1, (No such device or address)
Julius2: drmOpenDevice: open result is -1, (No such device or address)
spstarr: building test
Julius2: drmOpenDevice: Open failed
Julius2: it then goes on to look for card1, 2 3 etc
yangman: Julius2: delete your xorg.conf and see if it comes up with autodetect
spstarr: radeon_bo_test is running
spstarr: glisse: does it display anything?
yangman: Julius2: you won't have DRI unless you've installed the modules manually or running 2.6.30 kernel
Julius2: I've just spent the last 2 days fixing the problems I had with the auto-generated xorg.conf
spstarr: glisse: seems stuck ioctl(3, 0xc00c6463, 0xbfc93b44) = 0 ?
Julius2: when I ran X -configure
Julius2: it tried to use kbd and mouse drivers
soreau: Julius2: Well 1) You've come to the right place 2) Arch is not necessarily for beginners
Julius2: which arch dislikes
Julius2: soreau: what do you suggest
soreau: Julius2: ubuntu.
yangman: Julius2: try the autodetect route. just rename xorg.conf to something else
Julius2: what do you suggest?
soreau: Jaunty was just officially released yesterday as a matter of fact
Julius2: I've tried auto-detecting before
Julius2: but to humour you, I'll do it again
soreau: Do what again?
Julius2: use X -configure
Julius2: to generate a new xorg.conf
soreau: Oh yes, just rename or delete xorg.conf and let X figure it out
Julius2: I did that
Julius2: and, like I said
Julius2: the fact is that by default, X tries to use kbd and mouse drivers
yangman: huh? I said to get rid of xorg.conf entirely. not autogenerate a new one
Julius2: you can do without it?
yangman: 1.5.0 on
soreau: Julius2: mv /etc/X11/xorg.conf /etc/X11/xorg.conf.bak
Julius2: WHAT THE
Julius2: it works
Julius2: I'm happy it works
Julius2: but I tried this before and it didn't
Julius2: something I must have done
nanonyme: yangman: Will work even more reliably if radeon and radeonhd ever merge. ;)
Julius2: while trying to fix xorg.conf
nanonyme: (Atm might be a bit random if you have both installed)
soreau: Julius2: Glad you got it working ;)
honk: heya, should tv-out work on a "02:00.0 VGA compatible controller: ATI Technologies Inc RV505 CE [Radeon X1550 64-bit]" with 6.12.1 (on ubuntu 9.04)? I do see the output using atomtvout, but get no picture after activating it :]
soreau: honk: You know, I tried tv-out on my rv350 last night and it did not work. Just random scan lines on the tv
soreau: (on jaunty)
yangman: nanonyme: meh. no idea how the autodetect code works. wait until KMS sorts it out. FWIW, mergin is impossible. the only thing is to port code across so they reach feature equivalence
spstarr: soreau: tv-in works?
soreau: honk: Of course it was just a live session, I didn't play with it too terribly long
spstarr: soreau:do you get any picture on TVin our a ghost image wrapping around
soreau: spstarr: tv-in?
spstarr: you know TV tuner ?
spstarr: or you dont have
soreau: has no tv-in
soreau: spstarr: Nope, I plan on getting one eventually though
honk: I dont need or want tv-in, I want tv-out ;p
soreau: honk: What does 'xrandr' have to say about s-video? or how are you plugging the tv up?
spstarr: whats the use of TV out? displaying your computer screen on your TV? ;p
honk: xrandr shows the tv just fine
soreau: spstarr: At 800x600 hard coded, it's pretty useless I agree
soreau: At most you could put a visualization on it I guess
soreau: honk: Does it show it's connected? As S-Video?
soreau: honk: The resolution you have set for the tv is too high. You have to use 800x600
honk: I dont
honk: the tv can do more than that resolution ;P
honk: anyway, I'm currently fighting with xrandr
honk: xrandr --output S-VIDEO --mode 800x600 --left-of DVI-0
honk: that dosnt seem to have any influence at all :]
honk: errh.. never mind
honk: as I said: same behaviour with 800x600 ;)
honk: oh.. and when I enable the tv, I get corruption on the primary screen
soreau: At what resolution?
honk: any resolution
honk: and no screenshot, I dont have a cam
soreau: Well, it's probably the driver version jaunty has packaged
honk: it's been like this for ages
soreau: Since my regular proceedings didn't get it working, I am thinking jaunty is weird with xrandr or their default radeon driver install/setup
honk: the corruption is easily avoided by changing the resolution
honk: there's no tv-out anyway
honk: soreau: changing it back and forth
honk: the resolution itself has got no influence - changing it does
honk: http://nopaste.info/5b0be806ed.html <-- primary screen is just fine (after swapping resolutions)
honk: tv is showing nothing at all :]
soreau: Try 'xrandr --output S-video --auto --right-of DVI-0' ?
soreau: idk, it's not working here on fedora either
glisse: spstarr: likely a problem with the build
glisse: it doesn't display anythings
glisse: it will print message only if error happen
honk: soreau: what's that supposed to be good for? the modes are set up just fine =)
spstarr: glisse: so it just sits there?
glisse: well he does things
spstarr: glisse: it doesnt change memory alloc?
spstarr: ok let me run it again
spstarr: ok it's running...
honk: what else o.O
spstarr: well, yeah
glisse: spstarr: it should runs for about ~3min
spstarr: glisse: ok letting it be.
glisse: better don't do anythings while it's running
spstarr: glisse: in the meantime i have corruption all over the place now
spstarr: text glupths lines garbage stuff
spstarr: bahhhh glyphs
soreau: pat pats spstarr
spstarr: i cant even see some letterrs now
glisse: spstarr: i am rebuilding on my agp box will test it soon
spstarr: glisse: it ran, exited with no error/msg
glisse: spstarr: but still you see corruption
spstarr: glisse: im going to guess you need some erratas to workaround this?
glisse: spstarr: well i will see how my agp r9600pro cards behave i think i have few of them
spstarr: glisse: im ready to test on the fly
glisse: spstarr: well if i see same things it's easier
spstarr: glisse: you should on a M10 9600 mobile
spstarr: glisse: or if you could limit the vram used to < 64MB
glisse: i could limit vram
glisse: but i think i even have a 64M card
dileX: glisse: w/ you drm-next-radeon kernel and modeset=1 should there be a resolution change in init-3 (console) - no X started.
glisse: dileX: blackscreen
dileX: glisse: might you have a look at my kernel-dotconfig
glisse: dileX: got to go, bb in ~1h
glisse: will look then
glisse: dileX: what do you have ?
glisse: no mode change ?
dileX: starting in init-3 no resolution change - w/ drm-rawhide kernel I have it
glisse: dileX: dmesg or anyplace where kernel log endup should have a bunch of line newttm is quite verbose
glisse: pastebin that if you got any
spstarr: glisse: text glypths have become so bad.. i cannot see almost what im typing noww
spstarr: gross :(
dileX: cd ..
osiris__: glisse: unfortunately not all corruptions are gone. but it's much much better
spstarr: osiris__: i cant even read what you fully typed ;(
spstarr: "Unfortunately, not all corruptions gon ut it u h u h tt r
glisse: dileX: don't build radeonfb
glisse: osiris__: what lind of corruption ?
osiris__: glisse: all rotated pixmaps are broken
osiris__: glisse: also some glyphs are corrupted
glisse: osiris__: what simple app have rotated pixmap ?
spstarr: glisse: you seeing corruption on agp?
glisse: i am not yet on agp
osiris__: glisse: don't know, I'm using rotated plasmoids on kde4
glisse: osiris__: effect enabled ?
osiris__: glisse: no
spstarr: glisse: ok, its just getting hard to see your text responses :)
spstarr: glisse: the pattern is once it gets corrupted, it stays corrupted
glisse: spstarr: yup that sounds rational
spstarr: glisse: but it was gradually getting worse
spstarr: glisse: its stablized at a point
spstarr: glisse: awaiting your next code fixes.. i will have to drop back to airlied's kernel soon this is getting on my nerves ;/
glisse: spstarr: rawhide is now working for you ?
spstarr: glisse: rawhide will give me different corruption vs this with text glypths, rawhide is not stable forme now as i get hard lockups
spstarr: glisse: its all bad :(
spstarr: im just going to wait til you see AGP corruption
spstarr: glisse: we already know its occurs on other RV350 AGP.. otaylor has reproduced corruption exactly like mine
spstarr: with rawhide
dileX: glisse: is this intended with kms-enabled to get a dri2-enabled screen with Software Rasterizer :-)? here ati-x1300
glisse: dileX: somethings is wrong with libgl as a guess
glisse: LIBGL_DEBUG=verbose glxinfo should gives hint
glisse: top of the output
glisse: dileX: your mesa of radeon-rewrite is maybe outdated or isn't compiled against libdrm of modesetting-gem
dileX: glisse: I took your libdrm mesa and built my xorg against it.
glisse: i don't have my own libdrm
glisse: mesa: git://anongit.freedesktop.org/git/mesa/mesa branch radeon-rewrite
glisse: libdrm: git://anongit.freedesktop.org/git/mesa/drm branch modesetting-gem
glisse: don't need to build X against them
glisse: any X >= 1.6 should work but X from master will be better
dileX: which xf86-video-ati?
glisse: yeah that one
dileX: glisse: yepp, GLX Renderer Mesa DRI R300 20090101 x86/MMX/SSE2 TCL DRI2 GLX Version 1.4 Mesa 7.5-devel Direct Rendering Yes
dileX: glisse: so-to-say difference to airlied stuff is your drm-next-radeon kernel plus your radeon-gem-cs3 (xf86-video-ati) driver. interesting. easy to switch.
phoenix64: hm. What register is at 0x2184 on a rv530? r300-gallium writes to it, but I cannot find it in the docs -.-
phoenix64: ah. Is it documented somewhere outside of r300_reg.h?
phoenix64: ir is that why it says " /* GUESS */"? :D
glisse: maybe in r300 reg pdf
phoenix64: not the version I have here
glisse: it's mostly about what is send in the vtx stream
glisse: bit0 position, bit1 color0, ....
phoenix64: yeah, found that
phoenix64: hm, bit0 pos, bit1 normal, bit2 color, then the texture coordinates? That's what the header says?
markit: hi, I've an PCI ati 9200, debian sid 32, that worked fine since some update ago... now 2D acceleration seems disabled, I get 6FPS from glxgears at full screen, and driconf tells can't find device. http://www.pastebin.ca/1402303 of my xorg.conf. Any suggestion?
glisse: yeah it's the same as another reg i forgot about
markit: if I delete xorg.conf I have the same problem (works fine, but no acceleration)
Magnade: agd5f: i found something else for a slow down in firefox on the r100 card if you need another example
spstarr: glisse: any bits for mt to test?
glisse: spstarr: no i am investigating a fence issue it can be related to corruption
spstarr: ok :)
spstarr: i have to cut and paste your text into a konsole otherwise I can't read it :(
phoenix64: hm, does anyone know where r300-gallium sets viewport/window position+size?
phoenix64: MostAwesomeDude, played around with r300_gallium a bit more, seems that when I run trivial/quad, the viewport is completely off. glClear always clears the top left corner of the screen, and the quad gets spread across the top screen edge as the pitch is wrong so that multiple lines are renders on one height.
phoenix64: rv530. is that already known? Is it supposed to be like that atm? :D
MostAwesomeDude: phoenix64: So you're on a TCL chipset and RADEON_NO_TCL doesn't help?
phoenix64: I do use RADEON_NO_TCL
phoenix64: no idea what kind chipset this is, I don't know anything about radeon chips :D
phoenix64: heck, I was happy when I succeeded to hardcode a coloured tri into surface_fill :D
phoenix64: (*there* it gets displayed correctly btw, with correct screen pitch)
phoenix64: hm, but what's getting drawed of that quad isn't the same all the time either -.-
MostAwesomeDude: I really should put more code into the vert shaders to make them work right.
MostAwesomeDude: If you could acquire a list of "unimplemented opcode" and "unknown opcode" errors, that would be helpful.
phoenix64: eh, and I can find those where?
MostAwesomeDude: Should be popping up on stderr alongside the rest of the debug info.
phoenix64: in quad?
phoenix64: huh, quad-tex-2d shows a quad which looks like a miniature version of what quad should have shown :D
phoenix64: no unknown opcodes either though
phoenix64: huh, now the quad gets shown correctly, but at the top left edge, at the correct position relative to the background
spstarr: glisse: it is very interesting that the text glypth corruption has not corrected itself
spstarr: vs airlied's kernel which would gradually begin to make the text readable again
phoenix64: MostAwesomeDude, one bug: glClear has to be called before anything being rendered as it sets the screen pitch (in r300_surface_setup?)
spstarr: im still having severe text corruption and i can only make out some sentences by cut and pasting them
spstarr: even VT switching doesnt clear it
spstarr: goes into airlied's kernel with PCI on and KMS off
spstarr: corruption with KMS + PCI mode?!
spstarr: well, at least it isn't impacting text yet
spstarr: airlied's bits
spstarr: + DDX from glisse
MostAwesomeDude: phoenix64: Yeah, r300_emit_fb_state needs to set pitch.
phoenix64: doing that right now :D
phoenix64: MostAwesomeDude, like this? http://rafb.net/p/Abb1zw51.html
phoenix64: uh, lol, wait ^^
MostAwesomeDude: phoenix64: Should be set per-colorbuf, each of colorpitch[0-3] can be different for each MRT.
phoenix64: uh, yeah
phoenix64: somehow makes sense -.-
MostAwesomeDude: Lemme reboot into my dev environment and see if I can whip something up.
phoenix64: http://rafb.net/p/JJnWHF67.html -.-
phoenix64: ah, wait
spstarr: MAD: how goes ur r300 gallyum stuff ;p
MostAwesomeDude: spstarr: Gettin' back to it after two weeks. :3
soreau: needs to learn how to use xrandr better
soreau: I am readin the man page and all I am trying to do is change the resolution on my main monitor :p
soreau: but no luck
phoenix64: http://rafb.net/p/5yppmr21.html - now even with 100% more z buffer pitch -.-
phoenix64: does that at least partly look correct?
phoenix64: well, I'm off, gn8
soreau: I figure it out, and it killed vncviewer
osiris__: agd5f: how does the front/back color selection work on r300/r500 hw?
spstarr_home: crashed with firefox
spstarr_home: is now in non-KMS non PCI
airlied: this clamp thing goes a lot deeper, ass its regressing all over the place
airlied: like how can an R value we don't use cause problems.
MostAwesomeDude: Could be worse. r300-gallium isn't drawing prims anymore. Something bonghits happened while I wasn't looking, apparently.
b0le_: airlied: with regards to the front buffer patches to xserver master, I have copied the changes from intel (mesa), to radeon (http://pastebin.ca/1402470), and -sb and -db is now working with trivial/clear, but glxgears isn't rendering properly (it is flickering between the top-left of the screen, and the gears, mainly the top left of the screen though). Is there anything obviously different from intel that needs to be accounted f
b0le_: or in that patch?
airlied: b0le_: it might need DDX changes.
b0le_: airlied: from what I can tell, there was no changes to intel ddx for that
b0le_: hmm, maybe not, I do see something from Ian in there, I'll see if that helps.
osiris__: airlied: try setting output texcoord component count to 4
airlied: osiris__: I'm thinking I need to revisit the place where we set the 4 components in the VAP
airlied: I erally never liked it and wondered why it worked at all.
airlied: I'm not near any hw to play with at the moment.
osiris__: airlied: I've been hitting some texcoord related lockups too
osiris__: airlied: when I was trying to send only one texture component (and set to 0, 0, 1 rest of them in RS) it locked up
osiris__: airlied: but not always - I could only reproduce the lockup in sauerbraten game. don't know what was so special about it
osiris__: airlied: anyway, after agd5f suggestion now I always set 4 texcoord components in OUT_VTX_FMT_1, and it doesn't lock up anymore
airlied: seems like we do already
osiris__: airlied: of course RS_COUNT.IT_COUNT need to be updated properly
osiris__: airlied: no, currently we always output only 2 components to RS
airlied: the thing is we then select R to be 0 in RS
airlied: at least on r500
airlied: oh yes we only set 2 there.
airlied: its the prog stream cntl we set to 4
airlied: or at least enable write for 4
airlied: I never liked that
osiris__: airlied: enable write is only for vertex shader input. what gets send to RS is specified by OUT_VTX_FMT_1
airlied: yeah but I'm just wondering where the hell the R values are comign rom
spstarr_home: airlied: glisse's kernel has corruption matching yours now.
spstarr: airlied: KMS on, PCI mode wedges GPU with firefox :(
spstarr: Linux segfault.sh0n.net 220.127.116.11-106.fc11.i586 #1 SMP Wed Apr 22 14:02:31 EDT 2009 i686 i686 i386 GNU/Linux
spstarr: im now in non-KMS and PCI mode
osiris__: airlied: hmm, it's really weird it is even trying to use R component for 2D texture
osiris__: airlied: maybe hw guys will be able to tell what is the proper way of programming it
b0le_: airlied: you were right, ddx needed a patch. Should I send them to the list, or is putting them here alright? For mesa: http://pastebin.ca/1402497 and ddx: http://pastebin.ca/1402498
airlied: b0le_: send them to the list, it'll scroll off before I get back to work :)
b0le_: mesa3d-dev is the right list?
airlied: or dri-devel
spstarr: airlied: according to wikipedia my chip can use AGP 8x?
spstarr: hasn't tried
spstarr: its not a Pro Turbo which was 4/8x
spstarr: tries it
koolfy: hello people :)
spstarr_wap: airlied: how come agp is restricted to 1 2 and 4x only?
spstarr_wap: Would be nice to override
spstarr_wap: Nevermind lspci says 1 2 4
spstarr: cries fowl on http://en.wikipedia.org/wiki/Comparison_of_ATI_Graphics_Processing_Units#Radeon_R300_.289xxx.2C_X10xx.29_series
spstarr: unless they did make the 9600 M10 also with AGP 8x
spstarr: unless we're misdetecting this or lspci's info is wrong
spstarr: Performance, technologies and features listed above can vary with specific notebook implementations.
spstarr: yes it is 4x model 2373CXU is 4x only