airlied: AbortRetryFail: wierd I have working rotated zaphod on my laptop :)
airlied: AbortRetryFail: I just pushed the cursor fix to master.
airlied: another bug with pciaccess that I'll have to think about
airlied: AbortRetryFail: okay now it even works on pciaccess servers.
airlied: hmm EXA looks made of fail on zaphod.
airlied: hmm EXA looks made of fail on zaphod.
MostAwesomeDude: zaphod? Is that...dual-head?
airlied: MostAwesomeDude: old-skool dual-head
airlied: okay I think I've fixed the worst bugs that 10 mins testing can find.
MostAwesomeDude: airlied: Heh, I get the joke. So what's the difference between that and randr12?
airlied: MostAwesomeDude: one is big desktop the other is two desktops.
MostAwesomeDude: Ah. Cool.
roh: hm. ive also got some weird bugs left here with xrandr and so
roh: will pull git again and retest
MostAwesomeDude: wants his laptop!
airlied: and that completes the yearly zaphod fixup :)
roh: hm. the fresh git from today breaks 3d
roh: drmRadeonCmdBuffer: -22
roh: [ 419.544000] [drm:r300_emit_carefully_checked_packet0] *ERROR* Register 4600 failed check as flag=00
roh: [ 419.544000] [drm:r300_do_cp_cmdbuf] *ERROR* r300_emit_packet0 failed
roh: first from the shell-output of glxgears as it bombs on startup, last 2 from the kernel dmesg
airlied: roh: you need new drm for r500
roh: and the flickering of my mouse-cursor: it really goes away when i switch both heads to the same single view (--same-as) .. with --right-of it flickers
roh: airlied i did i have.
roh: eh think
roh: agd5f' tree
airlied: roh: it needs the patch that I checked into master.
airlied: I can't push to his tree.
roh: is his stuff in master now?
airlied: roh: nope.
airlied: I should pull it in really.
spstarr: airlied: all DRI locking issues with the r300 are resolved in F9? hmmmm...
spstarr: will need to confirm that one still for me.
airlied: spstarr: no just the one in that ubg
roh: this decentralised repo stuff still needs some reconsidering ;) atleast from the 'what does one need to pull where and when' %-)
airlied: spstarr: one bug == one fix.
spstarr: i will try to reproduce the crash in a few mins
airlied: roh: this stuff isn't meant for use yet.
airlied: roh: its called development.
roh: i know.. we have 3 different kind of own repos in the company and depend on basically any kind of scm opensource projects use out there for the builds
airlied: even with a central repo it wouldn't matter we would just keep patches on websites.
roh: airlied still, in a open development its neccessary for people to try out that stuff so you can get proper reports. especially on drivers for shitloads of similar but not identical wiring
roh: sorry for the nagging but since it worked so well already and i do not see a reasonable alternative than no accel at all i am bound to use that stuff ;)
airlied: roh: that happens when we pull it into master :-)
roh: any idea about that flickering?
airlied: which flickering?
roh: the mouse cursor flickers when i use a 2 screen xrandr setup
roh: when i 'clone' then its not there
roh: when i use --right-of its there. its like a 20-40 pixel wide bar every few cm
roh: airlied i have tried capturing it on video.. mompls...
airlied: roh: can you pastebin your loffile
airlied: logfile even.
roh: wow.. huge.. mompls.. will put it onto webspace and add the videos
MostAwesomeDude: airlied: Nice work on the FP-related stuff.
MostAwesomeDude: I expect this will make just about everything work.
MostAwesomeDude: Well, for the implemented opcodes, at least.
roh: airlied http://yamato.hyte.de/xorg-ati/flicker-bug/
roh: put my corg.conf and the log there, the readme describes the bug, the videos are still uploading
roh: first vid is up (no error case) .. second takes 10 minutes (its huge.. hd stuff)
airlied: roh: wierd doesn't happen her.e
roh: 4 minutes for the error vid
airlied: roh: is that a t60p?
airlied: what desktop you running? gnome?
roh: the external screen is a old sgi screen with dvi/vga converter
roh: yes gnome
roh: its still a ubuntu gutsy
airlied: you're server won't let me play the vids.
airlied: but my t60p plugged into my 1680x1050 external monitor doesn't show anything
roh: oh.. sorry.. chmodded.
roh: now both vids are up
airlied: either the does it happen with XAA?
airlied: oops does it happen wiht XAA?
roh: not sure
airlied: EXA in gutsy server is quite old
MostAwesomeDude: airlied: I'm off to bed. Will test all the new delicious FP code tomorrow morning. Night.
roh: uhm.. well.. then this propably has to wait till after the next full backup
Zajec: do you developer-guys are subscribed to email@example.com ?
airlied: Zajec: yup..
Zajec: ok, so won't yell about my report update here ;)
MrCooper: airlied: EXA shouldn't really matter for the hardware cursor though...
MrCooper: roh: does this only happen at the top of the screen?
roh: MrCooper nope. its bars going over the full screen height
airlied: MrCooper: I can't think what else could cause it to get messed up when with the same virtual here I can't reproduce it.
airlied: roh: test with XAA is probably the easiest test.
MrCooper: hmm, that sounds like a bug of early pre-production AVIVO chips
airlied: roh: do you have any rotations?
airlied: I'll take that as a no :), you aren't rotatiing the screen.
airlied: MrCooper: well agd5f checked in a cursor locking fix the other day.
airlied: Zajec: the atombios fail?
roh: nope. i am not using my t60p and the sgi screen in 0G ;)
MrCooper: airlied: that bug couldn't be worked around, but it should be fixed in production hardware
airlied: MrCooper: I also have nearly the same t60p here though.. and its a firegl chip
airlied: so you'd hope it would be better ;-)
roh: MrCooper any idea how to proove its a hw bug to ibm?
Zajec: airlied: detecting EDID
MrCooper: yeah, weird - doesn't look like the cursor image should be getting updated all the time either, should it?
airlied: roh: try with XAA.
airlied: MrCooper: not really.
roh: ive still got next businessday service here, and no reason to keep a defective hw
MrCooper: roh: it probably isn't
MrCooper: maybe if you can find another unit that doesn't exhibit the problem...
airlied: try with an F9 liveCD :)
roh: whatfor that? punish me?
roh: (any rpm stuff hates me)
roh: will test xaa next time i restart the x11 here.. need to do something productive
Zajec: ServerDebugging on wiki tells I need xorg-x11-server-debuginfo - i use openSUSE... is xorg-x11-server-sdk what I need?
MrCooper: that sounds like development stuff rather than debugging symbols
Zajec: is this possible that simple xorg-x11-server has debugging symbols? can I check this somehow?
airlied: Zajec: btw did you try changing cables? or are you using different cables for each monitor?
Zajec: i used two different cables
MrCooper: Zajec: attach gdb, get a backtrace, see if it's useful
Zajec: MrCooper: oki
Zajec: airlied: plus i tested third monitor i didn't mention in bu report with third cable
airlied: Zajec: very strange DDC is so broken.
Zajec: airlied: i used http://substantiel.dyndns.org/libre/xresprobe/ddcprobe/ is this ok?
airlied: Zajec: t may just return the internal monitor.
airlied: depending on the bios.
Zajec: if i understand you... that's right - ddcprobe detects only my LVDS (and only in ~50% tests)
airlied: Zajec: I wonder does fglrx work.. it might be a useful test as a datapoint
Zajec: uh, fglrx is problematic for X700 mobility... i usually ends with black screen (like a few other users)... but maybe it'll work somehow for a moment
Zajec: airlied: will try this little later
spstarr: notices he has "Open Source Graphics Drivers - They don't kill kittens" still
spstarr: airlied: your 2006 talk @ OLS
spstarr: should archive these somewhere for people
Zajec: crashing his Xorg
Zajec: damn... my Xorg doesn't crash anymore
spstarr: ok, let's ssh into the laptop and trigger DRI crash log for bug
spstarr: watch it not crash
spstarr: composite is now on... turning off
pspstarr_4: May 6 04:01:46 segfault kernel: [drm:radeon_cp_idle] *ERROR* radeon_cp_idle called without lock held, held 0 owner f4c8c480 f6b08d00
pspstarr_4: May 6 04:01:46 segfault kernel: [drm:radeon_cp_reset] *ERROR* radeon_cp_reset called without lock held, held 0 owner f4c8c480 f6b08d00
pspstarr_4: May 6 04:01:46 segfault kernel: [drm:radeon_cp_start] *ERROR* radeon_cp_start called without lock held, held 0 owner f4c8c480 f6b08d00
pspstarr_4: over and over
pspstarr_4: known issue?
pspstarr_4: had to kill X was dumping log over and over
airlied: pspstarr_4: is that the backing store one or KDE one?
pspstarr_4: Xorg config # Option "BackingStore" "false"
pspstarr_4: not used
pspstarr_4: this is triggered when i disable composite with kwin
pspstarr_4: Option "XAANoOffScreenPixmaps" "True" only used and resize of GART
pspstarr_4: kwin being the KDE window manager
pspstarr_4: any of those addresses found in System.map?
pspstarr_4: going back to laptop..
spstarr: airlied: thats the crash i get and can reproduce 100%
spstarr: radeon_cp_idle() -> radeon_cp_reset() -> radeon_cp_start() -> to begining
spstarr: will BZ
MrCooper: spstarr: the bug is that the idle ioctl is getting called without the DRM lock held, you need to find out where this is happening in the X server
spstarr: any pointers in debugging that one?
spstarr: im not sure how the flow of who sets a DRM lock is done
MrCooper: spstarr: e.g. set a breakpoint in the failure path of drmCommandNone()
spstarr: can do
spstarr: i assume this is a kernel bug though? being triggered by userpace?
spstarr: or is it an X Server <-> kernel bug specifically
spstarr: nothing to do with kwin itself since it doesnt deal with setting any DRM locks the X server will
MrCooper: yeah, as I said it's probably an X server bug
spstarr: ok i'll log this under Fedora BZ for Xorg server... though it would be nice if the kernel just aborted if it detected a non held lock?
airlied: its a kwin bug because I don't use it and my system works ;-)
spstarr: still a bug
airlied: spstarr: so it only happens when you turn compositing off?
spstarr: or switch composite settings
spstarr: ie: the Texture filters
spstarr: Nearest (fastest), Bilinear, Trilinear (best quality)
airlied: wonders is kwin threaded or something..
spstarr: it being 4:40am i kinda need sleep :)
airlied: spstarr: does the F9 kwin have composint?
spstarr: it does
airlied: I might try tomorrow then.
spstarr: the KDE distributed is KDE 4.0.3
spstarr: my development environment is right now 4.00.72 (soon 4.1) but i can also try with 4.0.3's kwin
spstarr: i dont see how it kwin's fault directly anyway when it just hands anything to the X server
airlied: spstarr: well its doing something silly, compiz and metacity don't die on me ;-)
spstarr: yeah compiz (desktop effects) works just fine
spstarr: there is a Fedora BZ #445331 i will dump additional debug today when i get home
spstarr: ive noticed this issue ever since i switched laptop to Fedora
MrCooper: spstarr: the DRM is refusing...
airlied: hmm I can bonghit around with kwin no worries here.
MrCooper: airlied: with GL compositing?
airlied: MrCooper: yup..
airlied: on my x300
airlied: just trying with XAA.. was using EXA
airlied: I'm sure spstarr has all sorts of bongiht plugins turned on.
MrCooper: right :)
airlied: oh it did something bad that time.
airlied: its hung just no ssh to find out why.
airlied: ah well tomorrow can fix that..
MrCooper: one more reason to switch radeon to EXA by default? :)
Zajec: hi, have some question about radeon and color depth
Zajec: i noticed that when I use DefaultDepth 16, every time I run nexuiz, my Xorg crasehs
Zajec: is this radeon bug? or nexuiz?
Zajec: oh and when I use DefatultDepth 24 it works great
glisse: Zajec: which card ?
Zajec: X700 mobility
glisse: for 3d on r3xx/r4xx i would say that 16bit is not supported properly right now
glisse: we did all the RE in 24bits mode and things for 16bits are not yet fixed
Zajec: ah, that way
Zajec: ok, thanks for explaination
Zajec: should I play with this crash providing debugging info? or developrers will not relly interested in fixing that?
glisse: it will be fixed along the way, problematic area are more or less know
reppel: Hi, I'm having some problems with Xv. Basically, sometimes, when i maximize or move a window over the window playing a video via Xv, X lockups. I'm using xf86-video-ati git and drm-git, with mesa 7.0.3 and xserver-xorg 1.4. Do you have suggestions?
reppel: s/lockups/locks up
reppel: it only seems to happen when i run xcompmgr though
AbortRetryFail: reppel: have you checked /var/log/Xorg.0.log for any useful info when it crashes?
spstarr_work: airlied: I have an rv350, is the X300 series r3xx?
reppel: AbortRetryFail: it could be http://bugs.freedesktop.org/show_bug.cgi?id=15824
mattst88: spstarr_work, rv350 looks like it's radeon 9600 and similar
spstarr_work: but is a X300 also a r3xx?
spstarr_work: or newer
mattst88: but yes, X300 is r300 (rv370)
mr_moe: hi guys
mr_moe: i try to activate my second screen on my laptop with a x600 radeon card
mr_moe: i tryd xrandr --output VGA-0 --auto --right-of LVDS but the VGA screen remains dark
mr_moe: what can I do to find my failure?
PSYCHO___: try --output VGA-0 --mode RESOLUTION --right-of LVDS
mr_moe: nothing happens
mr_moe: xrandr only shows a little * behind the resolution of the VGA-0 section
mr_moe: so I think the driver trys to send data to the screen
mr_moe: but it is just dark
PSYCHO___: i guess it is not complaining about small virtual
PSYCHO___: and what version of driver do you have?
mr_moe: no. my virtual is big enough Screen 0: minimum 320 x 200, current 2960 x 1050, maximum 2960 x 1050
spreeuw: you may be past the maximum width
PSYCHO___: i have the same
PSYCHO___: Screen 0: minimum 320 x 200, current 3080 x 1050, maximum 3080 x 1050
PSYCHO___: and it works
mr_moe: i use the debian testing package and i think the driver version is 6.8.0-1
spreeuw: it's a miracle
spreeuw: glxinfo works again
mr_moe: did you mean this "server glx version string: 1.2" ?
spreeuw: no I meant my own build suddenly started working again
mr_moe: ah ok
spreeuw: mr_moe: I do knwo that randr came in radeon driver a bit later
mr_moe: anyone any idea why my second sreen wount work
spreeuw: mr_moe: is it disabled?
spreeuw: check in your xorg.log if a vga head gets detected
spreeuw: and man radeon
mr_moe: no it seams to work but it just shows black color
mr_moe: in xrandr i see the second screen
spreeuw: hmm I think I had that bug once too
mr_moe: and it seams to be enabled
spreeuw: is the monitor light green?
mr_moe: in my case blue but i know what you mean
mr_moe: and if i make xrandr --output VGA-0 --off the monitor goes into standby mode
spreeuw: are you using a snapshot of the xf86-ati driver?
mr_moe: öhmm I don't realy know. debian xorg testing driver?
mr_moe: do you know how to verify the driver version
mr_moe: any ideas?
spreeuw: sry nope
spreeuw: the logfile will mention it
mr_moe: vendor="X.Org Foundation"
mr_moe: compiled for 220.127.116.11, module version = 4.3.0
mr_moe: Module class: X.Org Video DriverABI class: X.Org Video Driver, version 2.0
spreeuw: in any case, it may be worth trying out a developement driver
mr_moe: how to do that
leio: hrm, numerous corruptions with rotation. Got to update stuff before investigating further
MostAwesomeDude: Good afternoon. I have my laptop back.
MostAwesomeDude: airlied: I hooked up max_temp_idx. We now get a very reliable (and very wrong) render for tri-add.
MostAwesomeDude: We need to swizzle constants to get tri-max and tri-min working.
MostAwesomeDude: The default tex shader is almost running.
jcarlos: hi, I'm trying to update my mesa tree but I get this when running 'git pull':
jcarlos: error: Entry 'configs/linux-dri' not uptodate. Cannot merge.
jcarlos: I modified that file when building the drivers...anything I can do?
otaylor: jcarlos: 'man git-stash' may be helpful
MostAwesomeDude: airlied: glxgears drops from ~2500 to ~1300 FPS when we emit the max_temp_idx, regardless of whether or not we set max_temp_idx.
jcarlos: otaylor: thanks!
MostAwesomeDude: Any idea what R500_PIXSIZE defaults to?
MostAwesomeDude: jcarlos: If you make any local commits, git-fetch and git-rebase are preferred to git-pull.
jcarlos: MostAwesomeDude: like when applying a patch, say, from bugzilla?
MostAwesomeDude: jcarlos: Well, whenever you git-commit.
MostAwesomeDude: git is confusing.
jcarlos: well, I only commit my hopes, so it doesn't apply I guess
kernel_panic: oops, wrong channel
MostAwesomeDude: airlied: Okay, last one for now. Gotta go to class. glxgears is fast again and I took a stab at OUT after TEX. Back later.
airlied: wonders where agd5f has gotten too :)
MostAwesomeDude: airlied: Evening.
airlied: MostAwesomeDude: hey.
MostAwesomeDude: airlied: We're getting closer, I think.
MostAwesomeDude: Just pushed TXB and some cleanup.
airlied: MostAwesomeDude: nice..
airlied: MostAwesomeDude: I must checkout latest changes.
MostAwesomeDude: mednafen with Minish Cap.
MostAwesomeDude: Still has massive issues,but it's a lot farther than before.
airlied: btw I thni kyou may still need the input vs temp counting code.
airlied: I'm not sure how you decide whats an input vs temp at the moment when setting up the temps
MostAwesomeDude: airlied: Yeah, I know. All I know for sure is that src(0) is input, and dest doesn't matter for output.
MostAwesomeDude: But dest(0) shouldn't mess up src. I think.
MostAwesomeDude: Or... I has an idea. Be right back.
airlied: well the inputs are put onto the pixel stack.
airlied: before running.
airlied: so you have to avoid trampling them with temps.
MostAwesomeDude: airlied: Right.
MostAwesomeDude: Mesa program:
MostAwesomeDude: # Fragment Program/Shader 0: TXP TEMP, INPUT, texture, 2D; 1: MUL OUTPUT, TEMP, INPUT; 2: END
MostAwesomeDude: INPUT, is that right?
airlied: depends on what texture units and colors are enabled etc.
airlied: and the outputs from the vertex shader
airlied: hence why you need some sort of input/temp allocator like r30
airlied: r300 even
MostAwesomeDude: airlied: Well, if I can trust VAP and Mesa, I can just let the shader pull pixels from whatever source it likes, and then bump max_temp_idx to properly size the pixel stacks.
airlied: MostAwesomeDude: nope, the input and temp namespace are separate in shader language
airlied: but not on the chip
MostAwesomeDude: Oh, I see.
airlied: so you need to allocate mesa temps from the pixel stack after mesa inputs
airlied: hence the r300 allocator
MostAwesomeDude: Well, inputs aren't changeable, right? That's up to the VAP, etc.
MostAwesomeDude: But I can just fit in temps wherever there's no pre-determined input.
airlied: MostAwesomeDude: hence the allocator.
airlied: MostAwesomeDude: it works out the inputs and then just puts temps in.
MostAwesomeDude: I don't have my Red Book with me. Are multiple inputs allowed for ARBfp and GLSL, or only one?
airlied: you need to know where all the inputs are before you can give out temps.
airlied: MostAwesomeDude: you have lots of inputs.
MostAwesomeDude: Multiple -> gotta pre-scan the prog for inputs.
airlied: MostAwesomeDude: you don't prescan.
airlied: MostAwesomeDude: you get a list read the r300 code
airlied: you have InputsRead
airlied: the inputs are all the texture co-ords and colors.
MostAwesomeDude: That commented block in init_program.
airlied: yup pretty much.
MostAwesomeDude: Well, gotta change locations, be right back...