airlied: twoerner: reproduced badness today, won't get to fix it until next week :)
spstarr_wap: Hello from my phone :
spstarr_wap: Airlied: I wonder how cgit looks from a phone so then I can keep an eye on you from......anywhere! :-)
spstarr_wap: Nice I can see airlied's diffs
arekm: finally figured out why resume from ram fails on git kernels... STACKPROTECTOR option was guilty
pkt: hmm, interesting
twoerner: airlied: oh, ok
twoerner: airlied: and how bad was it for you?
twoerner: airlied: do you know why it only happens with the KMS driver?
pkt: arekm: I think it might be responsible for my freeze too. What symptoms were you getting?
arekm: pkt: "moon" led on thinkpad was on but lcd turned off, black screen with cursor on upper corner, then sometimes lcd turned off again and then I wasn't able to force it to resume and the only thing I could do is to poweroff
arekm: and variations of "effects" above
pkt: hmm, I think it is something else in my case then
arekm: and what are your symptoms?
pkt: a total freeze on resume, display doesn't come up, doesn't even respond to pings
pkt: But that only happens with a kernel in Fedora's livecd
pkt: With exactly the same kernel, same config compiled on my ubuntu test system, there is no freeze
pkt: And I can get around the display staying blank with the restore vbestate quirk
arekm: zgrep STACKPRO /proc/config.gz?
arekm: this is quite new and experimental option, I doubt that distros enable it (but who knows)
pkt: no, it seems it isn't there
pkt: I thought it was but this was based on another kernel that was based in -tip after all
pkt: So it must be something else :/
pkt: at least I 'm pretty certain it is not AGP
airlied: twoerner: nope I reproduced it and went home :)
pkt: redhat should offer access to a big compile machine/cluster for Fedora kernels with a huge shared ccache :)
twoerner: airlied: so you do not know how bad it hit your filesystem?
airlied: twoerner: it was on a USB disk so I didn't look too hard
airlied: I'm going to find the fix using my USB key :)
twoerner: airlied: i am glad that it was reproducable for you ;-)
airlied: sorry it took so long to get to it.
twoerner: airlied: no problem - it is only important that it gets fixed before F-11 release
twoerner: airlied: because it will hit useres very hard
mjt: am i right thinking that kms requires framebuffer support?
airlied: mjt: yes
airlied: fb console support
mjt: (drm_i915 in 2.6.29 selects framebuffer stuff which I turned off in my config in 2.6.28 -- wonder if i shuold re-enable it again... ;)
mjt: aha. thanks!
mjt: (wanted to save some time in compilation step since i never, ever, used fb subsystem but always had it enabled -- just in time :)
airlied: twoerner: I think I have a fix
twoerner: airlied: ohh... :-)
twoerner: airlied: do you have a pach?
airlied: just pushing a test into koji
airlied: twoerner: /win 4
airlied: damb build failed
twoerner: the source offset is the problem?
airlied: which is wierd so I supsect there might be something else :)
airlied: twoerner: http://kojipkgs.fedoraproject.org/packages/xorg-x11-drv-ati/6.12.1/3.fc11/
airlied: I'm still looking for anything else :)
airlied: twoerner: oh I think I see the other one :)
osiris__: darn, airlied has already sent pull request :/
airlied: osiris__: I can do another one if its not a major patch :)
osiris__: airlied: nope, it's nothing big
airlied: twoerner: okay -4 is in koji building now
airlied: twoerner: please try it.
twoerner: airlied: as soon as -4 is finished
airlied: twoerner: I can see why the system load was higher :)
airlied: using you 0 page to transfer video :)
osiris__: airlied: is there anything new to test?
airlied: osiris__: no I got distracted away from mesa today.
airlied: twoerner: sorry I still suck
airlied: forgot to fix the fix again
airlied: jeez I'm fail, 5 lines of chagnes and 2 different bugs in each line
twoerner: airlied: ok.. i will be back in 30 - 45 minutes - lunch time
airlied: twoerner: cool it should be in koji by then :)
glisse: airlied: your surface tilling stuff is not in rawhide ?
airlied: glisse: I'm trying to make sure I'm happy with the API :)
airlied: but I think I am mostly
airlied: also I had to fix some issues with fbcon surfaces
airlied: I think i need to pin the surface for it
glisse: well i am doing a rawhide patch (remove pin/unpin) it shouldn't conflict too much with your patch beside radeon_drm.h
glisse: fbcon only has a scanout buffer right ?
airlied: yeah I'll probably add the interfaces but leave tiling disabled until I figure out the last bits of it
airlied: glisse: yes
airlied: don't really need to tile it
airlied: was just testing using it
glisse: in my patch i pin/unpin in crtc set base
airlied: I think I already do that
glisse: just remove the userspace interface
airlied: just didn't drop the userspace api yet
airlied: also need to pin the cursor
glisse: well haven't done the code yet, i am switching branch
glisse: my hd is bit slow :(
glisse: i also got a ddx patch for cs3 branch
glisse: to remove pin/unpin
glisse: what sucks with this kind of thing is that you need to update everythings in one run
airlied: glisse: nothing is using it
airlied: glisse: the kernel already does it all, userspace stopped using it
glisse: ddx still has bit in it about the api
airlied: ah radeon_bind_memory
airlied: nothing should call that anymore
glisse: so then i am just chopping off stuff :)
airlied: yes pretty much, just dead bits :)
airlied: in the DDX I want to go back and remove lots of the pre-driver pixmaps bits that snuck in
glisse: yup ddx bufmgr stuff is bit messy
glisse: btw i wanted to remove dst_pipe_config in init3d engine with kms but somehow if i do so i get rendering issue (small corruption)
glisse: it's strange because kms is already setting the reg
glisse: with the exact same value as ddx
airlied: is mesa setting it as well?
glisse: haven't checked but lickely
glisse: though i think i tested without mesa
airlied: maybe the stall it causes is helpful or something
glisse: maybe it flush so cache we don't
airlied: whats the rendering corruption?
glisse: it's corruption on edge of triangle
twoerner: airlied: ok, back
twoerner: airlied: the fix seems to fix the problem
twoerner: airlied: and CPU usage went further down.. NICE
airlied: twoerner: excellent
twoerner: for X
twoerner: airlied: that is really cool
twoerner: airlied: it looks very good - no kernel oops
twoerner: airlied: do you have news on the mesacode for R6++ ?
airlied: twoerner: nothing new
glisse: airlied: you need the last fence stuff in sarea ?
airlied: sounds like something I don;t need
glisse: given there is not other userspace fence interface i think so
airlied: glisse: probably can drop all handles + pitches as well now
airlied: don't really need those sarea changes anymore
glisse: yup i am dropping them in my patch
glisse: i am syncing up radeon_drm.h
b0le: airlied: radeon-gem-cs3 is failing to compile due to, I presume, a typo: "_ScrnInfoRec has no member named fboffset". Changing it to fbOffset makes it compile.
b0le: yay, dri2 and compiz is finally working for me. Pity I haven't got a cube anymore :(
osiris__: glisse: ping
glisse: osiris__: pong
osiris__: glisse: do you happen to know who wrote smooth lines comment on http://dri.freedesktop.org/wiki/R300ToDo ?
glisse: i didi
osiris__: do you still have these dumps?
glisse: sadly no
glisse: but z3ro tools should have the proper demo
glisse: should be quite easy to do the dump
osiris__: yeah, but I would have to downgrade all graphics stack to be able to run fglrx
glisse: osiris__: you should keep a small part with old distro, like fd10 or ubuntu with fglrx on it
glisse: this is what i try todo
osiris__: agd5f: can you check if non tcl hw supports two sided lighting?
MrCooper: osiris__: isn't two-sided lighting purely a vertex pipeline concept, so non-TCL hardware shouldn't need to know or care about it?
rnoland: agd5f: are these patches good?
agd5f: rnoland: yeah
osiris__: MrCooper: I don't know. I know that r300 tcl hw allows for 4 colors, which I think vertex program modifies accordingly to current lighting state. so only 2 colors are left, and then SU (setup unit) selects the correct color basing on primitive facedness
rnoland: ok, cool... i never saw a reply, so wanted to check before i lost them...
agd5f: I think Dave already merged the first one
osiris__: MrCooper: and I want to know if non tcl hw also allows 2 colors (precalculated in sw) to be pushed to hw and SU will select the correct one
agd5f: osiris__: everything beyond the pvs should be the same
osiris__: agd5f: ok, will try doing two sided lighting partially in hw then for sw tcl path
rnoland: agd5f: that patch to use switch for microcode... Did you get that, or should I send the svn diff to the list?
agd5f: rnoland: I've got it, but you might as well send it to the list as well
agd5f: I haven't had a chance to merge it yet
rnoland: i already committed it to our tree
rnoland: i think i tend to be able to get things out to users more quickly...
agd5f: rnoland: who was the author again?
rnoland: r190595 | rnoland | 2009-03-31 12:52:05 -0500 (Tue, 31 Mar 2009) | 5 lines
rnoland: Simplify the radeon microcode loading.
rnoland: Submitted by: Christoph Mallon
buggs: what is neeed to have drm (for xv) for a hd4850?
buggs: with kernel 2.6.29
buggs: libdrm 2.4.5
buggs: mesa 7.4
agd5f: buggs: ati 6.12.1 or git master, drm from airlied's drm-next tree or drm from r6xx-r7xx-support branch of mesa/drm on freedesktop
agd5f: rnoland: patch didn't apply cleanly, so I changed a few things: http://220.127.116.11/alex/xorg/radeon_ucode.diff
rnoland: what failed?
rnoland: i thought we should be an exact match on that...
agd5f: everything but the declarations
rnoland: what branch is this diffed against?
rnoland: ah, ok...
rnoland: mine should be based on drm-next
agd5f: I haven't gotten to drm-next yet
agd5f: ah ok
rnoland: though i just realized that i need to sync up some more stuff...
rnoland: i don't have radeon_reg.h
agd5f: also some of the changes are probably worthwhile
agd5f: no need to mess with the hw at all if the chip doesn't match
rnoland: sigh... ok, i need to figure out what to apply this to, so I can see what is different....
agd5f: rnoland: I can post the new functions in thie entirety
agd5f: it's a trivial patch
rnoland: this is applying to git?
rnoland: if so, i'll just apply it there and diff things...
rnoland: agd5f: there are too many different code bases...
rnoland: i can pick out the diffs for this patch, but git is still somewhat different from drm-next
rnoland: agd5f: ok... what the heck is in drm-rawhide?
rnoland: it appears to have gem like stuff in it...
agd5f: rnoland: radeon modesetting and memory management
rnoland: is that newttm?
glisse: newttm is in my branch on fdo
rnoland: which branch is that?
rnoland: argh... ok...
spstarr: when is newttm being merged?
glisse: far from that poin yet
spstarr: what significant changes?
spstarr: oh this is your first commit into your branch
spstarr: glisse: it looks like from your patch you now have memory pools?
spstarr: 16 memory pools?
spstarr: for each IB
glisse: no it's ib pool
spstarr: oh that code is really early stages
glisse: well it works
Roberth1: isnt a custom virtual screen resolution supported with shadowfb?
Roberth1: no one?
AStorm: I've no idea, sorry
Roberth1: (EE) RADEON(0): Acceleration required for rotation
Roberth1: what does that mean?
agd5f: Roberth1: you can't rotate the screen without acceleration
Roberth1: agd5f: i dont even know what rotation means:p
agd5f: Roberth1: rotating your desktop 90 or 180, etc. degrees
Roberth1: agd5f: i just want to DVI-1 to appear to left of DVI-2
Roberth1: let me show you my xorg.conf....
agd5f: that should work finw
Roberth1: agd5f: http://rafb.net/p/wnnXoT43.html
Roberth1: http://rafb.net/p/5moDiR33.html some of my xorg log
agd5f: Roberth1: the output names are DVI-0 and DVI-1
agd5f: and depth should be 24
agd5f: Roberth1: http://wiki.debian.org/XStrikeForce/HowToRandR12
Roberth1: agd5f: well 32 bit depth works fine with only one monitor enabled
mcgreg: afaik there is no real 32bit depth :)
agd5f: Roberth1: that section won't get parsed properly otherwise
agd5f: depth 24 == 32 bpp on most hw
mcgreg: 32bit is 24bit + 8 bit alpha .. which is only for 3d
Roberth1: http://rafb.net/p/GwBnxA86.html better now?
agd5f: Option "LeftOf" "DVI-0"
mcgreg: and besides that, I think normal monitors/displays cant even show more than 24bit :) I think there are specvial gfx cards that show 36bit colours but they need special monitors to be displayed
agd5f: also you can remove the Option "DVI-1" "Monitor1" lines
mcgreg: I believe I've read that somewhere
Roberth1: agd5f: uhm you sure?
agd5f: Roberth1: yes
agd5f: Roberth1: also remove Option "Position" "3040 1680" and Option "Postion" "1680 0"
agd5f: you already specified the position with LeftOf
Roberth1: oh okay
Roberth1: agd5f: should I define a resolution for each monitor to avoid any confusion or?
agd5f: Roberth1: probably not
agd5f: if they are both 1680x1050 native, they should come up that way
Roberth1: agd5f: they arent
Roberth1: one is 1680x1050 the other one is 1366x768
agd5f: whatever their preferred modes are will get selected by default
agd5f: Roberth1: try it and see
Roberth1: brb 1 min
Roberth1: agd5f: dvi-0 appears normally, but dvi-1 doesnt appear at all
agd5f: Roberth1: what do you mean? comes up blank?
Roberth1: agd5f: "no signal" on it
agd5f: Roberth1: pastebin your xorg log
Roberth1: http://rafb.net/p/mlmjFR16.html most of it
agd5f: Roberth1: can you pastebin the first part?
Roberth1: agd5f: how do I get the first part up?
agd5f: cut and paste from your xorg log?
Roberth1: the whole log doesnt get into the file...
agd5f: Roberth1: do the monitors work individually?
Roberth1: agd5f: havent tried dvi-1
Roberth1: agd5f: but I dont understand why it doesnt work
Roberth1: agd5f: i think I need to set resolution on dvi-1 manually
agd5f: Roberth1: need to see the top of your log
agd5f: maybe it's getting set to a weird mode by default
Roberth1: agd5f: yeah
Roberth1: brb 1 min
Roberth1: agd5f: same thing with 1366x768 set as preffered mode for dvi-1
agd5f: Roberth1: what does xrandr say when you start up? can you pastebin that?
Roberth1: how do I get that?
agd5f: start a terminal and type xandr
Roberth1: agd5f: http://rafb.net/p/Y6IQKa23.html
MostAwesomeDude: agd5f: IIRC we haven't made EXA the default because it still sucks on some chips, right?
buggs: agd5f, thanks, seems like i'm only missing the correct drm branch
buggs: any idea about the eta on mainline ?
agd5f: MostAwesomeDude: we probably should just change it
agd5f: Roberth1: DVI-1 is off
agd5f: Roberth1: xrandr --output DVI-1 --mode 1360x768 --right-of DVI-0
agd5f: Roberth1: the * indicates the active mode
agd5f: the + is the monitor's preferred mode
agd5f: if there's no *, the monitor is off
Roberth1: agd5f: uhm your line puts dvi-1 at the right side of dvi-0, but I want it at left of
agd5f: Roberth1: xrandr --output DVI-1 --mode 1360x768 --left-of DVI-0
Roberth1: agd5f: now they just swap monitor
agd5f: Roberth1: ?
Roberth1: agd5f: dvi-1 appears on wrong monitor and opposite
agd5f: but they are both on?
agd5f: xrandr --output DVI-1 --mode 1360x768 --right-of DVI-0
Roberth1: agd5f: well now they are correct, but I want to move my mouse cursor to the left to reach dvi-1
Roberth1: not to the right
agd5f: Roberth1: use --right-of or --left-of to change their orientation
Roberth1: agd5f: well that swap the monitors
Roberth1: i think xrandr thing dvi-1 is the primary monitor, but its not
agd5f: Roberth1: there is no primary
agd5f: they are just two heads
agd5f: Roberth1: I'm not following what you are trying to do.
Roberth1: brb 1 sec...
Roberth1: agd5f: here is the thing
Roberth1: dvi-1 is my tv
Roberth1: dvi-0 is my monitor
Roberth1: dvi-1 is physicaly placed to the right of my monitor
Roberth1: there for I want to move my mouse cursor from dvi-0 to the left to get to dvi-1
agd5f: Roberth1: so | 0 | | 1 |
agd5f: so you want xrandr --output DVI-1 --mode 1360x768 --right-of DVI-0
Roberth1: | 1 | | 0 |
agd5f: xrandr --output DVI-1 --mode 1360x768 --left-of DVI-0
Roberth1: yeah but that places DVI-1 on my tv:(
agd5f: Roberth1: I'm not following you
agd5f: you mean panels and such?
agd5f: the monitors are just windows into your desktop
agd5f: you can move them around however you want
AStorm: I'm not getting what exactly he wants...
AStorm: I think you need a WM to put windows by default on the right screen
yangman: so... you want monitor to be the "primary" with TV screen to the right? why do you then want to have the mouse goto the TV when you move it off the left side of monitor?
AStorm: nfc, probably that's how they're physically placed?
Roberth2: agd5f: now to clarify
Roberth2: agd5f: I have removed everything exept virtual line in xorg.conf
agd5f: Roberth2: ok
Roberth2: agd5f: http://rafb.net/p/UTyTd994.html
agd5f: Roberth2: ok
Roberth2: now I have configured the tv to be to the left og the monitor
Roberth2: agd5f: uhm I mean right
Roberth2: *now I have configured the tv to be to the right of the monitor
agd5f: Roberth2: ok. isn't that what you wanted?
AStorm: is vsync in Xv supported for r6xx/r7xx?
Roberth2: BUT the tv is physicaly to the left of teh monitor
agd5f: AStorm: yes
AStorm: weird, I'm seeing tearing... do I have to flip some setting?
agd5f: AStorm: make sure dri is enabled
AStorm: it is
Roberth2: AStorm: and you need to use textured video
agd5f: Roberth2: DVI-1 is your TV, DVI-0 is your monitor
AStorm: how to make mplayer use textured video?
agd5f: AStorm: there is only textured video on r6xx/r7xx
AStorm: so it should use it already, hmmh
Roberth2: agd5f: uhm my video card is ati radeon hd 3870, can I get a dri/drm which works with this card somewhere?
agd5f: Roberth2: yes
AStorm: maybe the artifact I'm seeing is not novsync tearing...
nanonyme: agd5f: Anything new of the Mesa r6xx/r7xx? :)
Roberth2: agd5f: where?
agd5f: airlied's drm-next tree, or the r6xx-r7xx-support branch of the drm tree on freedesktop
agd5f: nanonyme: hopefully soon. just tying up some loose ends now
AStorm: agd5f, mmmh, you mean, 3D?
agd5f: AStorm: yeah
Roberth2: agd5f: but what about the drm/dri in the linux kernel?
Roberth2: agd5f: how does it work?
agd5f: Roberth2: it's already in 2.6.30
Roberth2: agd5f: yeah but I only got 2.6.29
agd5f: Roberth2: you can try the r6xx-r7xx-support branch of the drm tree
Roberth2: agd5f: this one? it seems to be some issues with kernel 2.6.29
AStorm: Roberth2, then pull in drm-next
AStorm: yes, the branch works fine too
agd5f: Roberth2: I think they are fixed since I merged in master
Roberth2: agd5f: drm-next much newer or?
agd5f: Roberth2: drm-next has lots of fixes that aren't in the old drm tree on fdo
agd5f: but for r6xx/r7xx either tree is fine
Roberth2: hm okay I will xorg's
Roberth2: agd5f: so when I install the new drm branch, it will look there automatically for drm that works with my card?
agd5f: Roberth2: you'll have to copy kernel modules to your kernel module tree
agd5f: cd linux-core; make drm.o radeon.o
yangman: Roberth2: http://wiki.x.org/wiki/radeonhd%3Ar6xx_r7xx_branch
agd5f: the replace the drm.ko and radeon.ko files in your kernel modules tree
Roberth2: where is linux-core?
agd5f: in the drm tree
agd5f: you on fdo
Roberth2: now ive run make drm.o radeon.o, thats it?
Roberth1: agd5f: do I need to recompile the kernel or something after copying the new modules to the kernel tree?
nanonyme: Roberth1: The exact opposite. ;)
Roberth1: nanonyme: which means?
nanonyme: If you compile the kernel after copying the new modules, you break the new modules.
Roberth1: so I compiled the modules, copyed them over to the kernel tree
nanonyme: Did you mean the module directory?
nanonyme: (As in, somewhere under /lib/modules, likely)
nanonyme: Then you could just do depmod -a and load then, I guess. :)
nanonyme: If you get a /dev/dri after modprobing radeon, it was succesful.
Roberth1: bah I think ill rather just stand the tearing until kernel2.6.30 is released
nanonyme: is enjoying the new Fedora testing version that had Xv out of the box :)
Roberth1: huh xv?
agd5f: Roberth1: no need to recompile, just run depmod -a
Roberth1: nanonyme: uhm does fedora have the new drm etc?
agd5f: Roberth1: also, you can't copy modules built against another tree
kdekorte: Roberth1, the Fedora 11 beta does
agd5f: they have to be used with the kernel they were built against
Roberth1: kdekorte: do they include git version or?
airlied: beta + updated -ati
nanonyme: Fedora 11 beta has some other neat stuff too that drm-next doesn't though. :)
kdekorte: I'm quite happy with the ati support in F11...
kdekorte: just waiting for 3d at this point... but not a show stopper
Roberth1: so if im clear now, fedora got the latest radeon driver and drm from git?
nanonyme: airlied: Btw, did you touch something related to r6xx-r7xx KMS lately? (As in, today or yesterday) It seems to have stopped working for me. ^^
kdekorte: Roberth1.... sorta
airlied: nanonyme: not i nthe last couple of days
Roberth1: maybe I shall try fedora its not a bad distro
kdekorte: only problem I'm seen with the beta is no-dpms in gnome-screensaver, which is annoying and a slight stutter when mplayer starts playing a video (xv or x11)
airlied: kdekorte: does the stutter happen with mplayer -ao null?
kdekorte: airlied... let me check... no it does not
kdekorte: I like the idea of pulse audio (which either pulse or alsa in mplayer use), but it still needs some work
AStorm: agd5f, btw, any avivo stuff or general programming interface planned?
nanonyme: I personally just killed PA until it gets better or dies out. ;)
agd5f: AStorm: avivo? you mean like video accel?
kdekorte: One of my favorite features of pulse (separate volumes for apps) got killed in the latest release.. I liked having the alter volumes high but the audio player lower
AStorm: agd5f, yeah, like h323 etc.
tlp: kdekorte: they removed that feature?
yangman: kdekorte: must be a UI thing. I can still do it
agd5f: AStorm: MC is done with the 3D engine, so all the info is already available
kdekorte: tlp, appears so with the new "flat" volume
AStorm: and hopefully deinterlacing (motion compensated, no less)
kdekorte: yangman... how
AStorm: agd5f, :)
nanonyme: kdekorte: I personally don't want other sounds at all when I'm listening to music. Each to their own. :)
AStorm: MC itself is not much
AStorm: deinterlacing is expensive, OTOH
AStorm: and the deblocking
yangman: kdekorte: pavucontrol still gives me the per-source volume control
kdekorte: yangman, when I set mplayer to use pulse and change the volume in it, it changes the master volume...didn't do that in f10
yangman: kdekorte: oh. that's a configuration thing. they must have changed the default volume control hook from the app one to the master one
yangman: kdekorte: I've never played with it, though
kdekorte: yeah, I want that feature back...
agd5f: AStorm: I think the texture units can deal with interlaced material on r6xx/r7xx.
rnoland: agd5f: any eta on 3d yet?
AStorm: dealing is one thing
AStorm: displaying it on a flat panel is another
agd5f: rnoland: soon :)
AStorm: that needs deinterlaced output
rnoland: agd5f: cool
rnoland: it makes me crazy how much time i have to spend on the intel driver, when ati just works...
rnoland: so far, even nouveau pretty much just works...
agd5f: rnoland: IGP chips are made of pain
MostAwesomeDude: And suffering. And GEM.
rnoland: and lack of attention to anything except gem....
AStorm: they're also made of cheap
kdekorte: The intel driver so far has been a disappointment...
AStorm: agd5f, the actual idea is to run mplayer's mcdeint on the card
AStorm: this is CPU-heavy
agd5f: AStorm: you can probably do it via the 3D engine somehoe
AStorm: yeah, like using that vdpau you don't support ;)
AStorm: api plz
agd5f: AStorm: documenation is available, patches welcome ;)
AStorm: hard to do w/o time :-(
nanonyme: agd5f: Wasn't there a Google Summer of Code project suggestion in X.org list about making a VDPAU state tracker with Gallium?
yangman: does vdpau have sane handling for the various different mpeg differences? because Xv is pain if you're after accurary
agd5f: nanonyme: last year someone wrote an xvmc interface IIRC
agd5f: I think there's a proposal to do vdpau this year
MostAwesomeDude: I suggested VDPAU and marcheu stepped up to mentor it, but nobody's actually submitted a proposal AFAIK.
MostAwesomeDude: Eventually ymanton or I will do it, but if somebody wants, they could ask marcheu about what needs to change in the Gallium video decoder interface.
glisse: agd5f, airlied: in fact there is issue with my fence code after a while my fence believe there is a gpu lockup but the gpu is doing fine, it's just that somehow it either fails to read the fence value or to wakeup the fence handler
glisse: only happen after a while for me
AStorm: uh, so xvmc is supported now? (r6xx/r7xx?)
MostAwesomeDude: AStorm: No.
MostAwesomeDude: XvMC will work through Gallium when r300 and r600 drivers get there.
MostAwesomeDude: wishes more people were interested in getting r300 working on Gallium
soreau: is interested in it
MostAwesomeDude: soreau: Awesome. Been reading the code at all?
soreau: I just wish I had programming knowledge to help you guys out
lilac: hi, i'm seeing a segfault on X startup in dixLookupPrivate if i enable DRI or Xinerama. can anyone help me to fix this? xorg.conf: http://pastebin.com/m330e294f logfile: http://pastebin.com/m47a400cb
glisse: MostAwesomeDude: i will definitly look into it once i get solid working kernel bit :)
soreau: MostAwesomeDude: No, only the tv-out bits I want to get 1024x768 working
MostAwesomeDude: glisse: I figured you already had it working in a private repo and would push it once you stopped laughing at my code. :3
lilac: (or should i be asking in #xorg instead? i have no idea if this is specific to the radeon driver)
glisse: MostAwesomeDude: i pushed everythings in my repo
glisse: drm-next, drm (modesetting-gem branc), xf86-video-ati (cs3 branch)
soreau: MostAwesomeDude: I have installed Fedora on a spare partition .. but I don't know what I'd have to do (which components to install including kernel etc) to become a tester
MostAwesomeDude: glisse: Just a joke. I've got stuff more or less working, but it's still very glitchy and buggy.
soreau: MostAwesomeDude: Which distro do you use for programming?
MostAwesomeDude: soreau: You'll need the radeon-gem-cs3 DDX if you're on Rawhide.
MostAwesomeDude: I'm on Rawhide. Works pretty well.
soreau: I want to be a tester for the latest dri2 stuff..
soreau: I have r350 (radeon 9600 agp)
glisse: damm can reproduce fence false lockup
soreau: But I don't know what I'd have to do or install to test it exactly
soreau: MostAwesomeDude: What is meant by 'Rawhide' specifically?
MostAwesomeDude: soreau: The unstable branch of Fedora.
MostAwesomeDude: I can't remember how to pull into it from stable, and it's kind of an icky process. You might be better off cherry-picking Xserver, kernel, libdrm from Rawhide instead.
soreau: MostAwesomeDude: Ok thanks. I'll ask how in #fedora
MostAwesomeDude: Wish I could help more, but TBH I still don't understand how the heck I got mine working. :3
MostAwesomeDude: I can tell you for sure that you only have to replace the DDX to get DRI2 working.
soreau: It's all good, I just needed to know that I need to get the unstable branch of fedora going ;)
agd5f: lilac: looks xserver related
agd5f: glisse: the times stamps fail to write?
agd5f: does truning off wriateback help?
lilac: agd5f: quite possibly. i'll see if i can get a better backtrace
agd5f: glisse: I think COND_EXEC and WAIT_MEM packet 3's may be useful for fencing.
agd5f: so you can schedule stuff, but it won't execute until a condition is met
agd5f: that way you aren't stalling anything else
agd5f: if it doesn't execute, just re-schedule
agd5f: although I don't think those packets existed on older chips
linmax: I'm trying again to get 2d acceleration on my r600 chip to work
linmax: I'm using latest git of drm/r6xx-r7xx-support and xf86-video-ati/master
airlied: MostAwesomeDude: yout don't have to do that anymore
airlied: the DDX does DRI2 in F11 beta
spstarr: airlied: how goes radeon-rewrite
linmax: but It down's work, after starting X the system is quite slow and I get this in dmesg: kernel: [drm] wait idle failed status : 0xA0003030 0x00000003
airlied: spstarr: its in the reschedule queue :)
spstarr: I'm watching http://www.100hoursofastronomy.org/
spstarr: a nice 100 hour distraction from anything
linmax: also the screen output doesn't look right
linmax: this is on a HD3470 in my PCI-e slot in my desktop PC
damentz: hey airlied, what game are you guys using as your benchmark for DRI2?
damentz: nexuiz 2.5 just came, maybe yesterday
linmax: here is my Xorg.0.log: http://pastebin.com/d70144829
airlied: damentz: gears :)
airlied: damentz: I don't benchmark yet
airlied: first up is correctness
damentz: so with dri2, you guys will be able to implement OpenGL 2.1 right?
airlied: once it doesn't have regressions vs the current stack then I can worry more about speed ups
airlied: damentz: if someone implements GLSL
airlied: itsnotthing to do with dri2 thuogh
airlied: you can implement GL2.1 with DRI1
nanonyme: chants Gallium
damentz: oh really?
damentz: is that what is in the plan for the cards unsupported by fglrx anymore?
damentz: the radeon 1900 xtx is still a wicked powerful card :\
airlied: well we don't really care about fglrx support
airlied: it doesn't affect us in any way whatsoever
airlied: the plan is the same plan we've always had
airlied: write drivers for AMD cards to support as much as we can in the time we have.
nanonyme: airlied: Is the main focus of attention going to be turned away from classic Mesa to Gallium when r600+r700 KMS + MM gets somewhat done, btw?
airlied: my plan would be finish my radeon-rewrite,get stuff upstream, and solid
airlied: then hope someone does r300/r600 galium :)
linmax: anyone has an idea for my problem?
airlied: I'm not sure we'll get GLSL on classic mesa r300
airlied: probably easier to just push gallium
airlied: shopping &
agd5f: linmax: does it work if you disable the DRI?
linmax: I think I tried it once and it did work, but I'll recheck
linmax: agd5f: looks fine it I disable DRI
Roberth1: airlied: what will be new in the rewrite?
agd5f: Roberth1: the new drm bits you get fbos and resizable freambuffers
Roberth1: whats fbos?
agd5f: linmax: log looks fine how much ram does your system have?
agd5f: Roberth1: framebuffer objects
Roberth1: agd5f: what are they good for?
linmax: agd5f: 1671MB HIGHMEM available. 887MB LOWMEM available.
agd5f: Roberth1: lots of fun GL stuff
Roberth1: wonders when netbsd is going update drm and dri
ajax: what's a netbsd?
Roberth1: netbsd is an operating system
rnoland: haven't heard from bjs lately... not sure what he is doing.
rnoland: dragonfly is riding my coat tails...
Roberth1: rnoland: who is bjs?
rnoland: the netbsd drm guy
Roberth1: rnoland: orly
Roberth1: rnoland: you got any mail to him? I would like to speak with him
rnoland: um, hang on...
rnoland: i'd guess that email@example.com works...
rnoland: but i don't see him in the 50k+ mails in my inbox.
Roberth1: rnoland: why would he contact you?:P
rnoland: <- FreeBSD drm guy
Roberth1: rnoland: is freebsd's drm updated?:P
rnoland: Roberth1: yep, we are shipping r6/7xx code in -CURRENT and -STABLE
rnoland: will go out in 7.2
Roberth1: btw, didn't know that netbsd guys ever spoke to freebsd/dragonflybsd/openbsd -people:P
rnoland: heh, we are so outnumbered here, that we have to rally together...
chithead: seems r6/7xx drm code is everywhere except netbsd and drm git master...
rnoland: the dragonfly guy contacted me a few days ago... to tell that they were shipping whatever i am..
rnoland: has it shipped in any linux yet?
Roberth1: anyway the netbsd drm wont ship until netbsd 6.0 I guess
Roberth1: rnoland: nah
Roberth1: rnoland: coming next kernel release
Roberth1: fedora got some trick done to ship afaik
rnoland: Roberth1: that is what i thought...
rnoland: he used to be on irc some...
spstarr: airlied: 11:30am in AU?
bridgman: spstarr; 11:30am on a Saturday, not the same ;)
bridgman: workdays you can lounge around and code, Saturdays you have to go grocery shopping
spstarr: bridgman: heh
spstarr: ive been off for 2 weeks doing nothing
spstarr: likely wont be doing much when i get back to 'work' monday
bridgman: if they pay you it's work
bridgman: if they start getting behind on paychecks then it's 'work' ;)
spstarr: chatting on irc is work then :)
edt: what git trees should I track to get the latest xf86-video-ati and drm code? I am now tracking git://anongit.freedesktop.org/git/xorg/driver/xf86-video-ati and git://anongit.freedesktop.org/mesa/drm (r6xx-r7xx-support branch)?
edt: with xserver 1.5.3
bridgman: edt; which GPU ?
mattst88: edt, r6xx-r7xx support has been moved to master branches, IIRC.
DanaG: Hmm, not sure about drm, though. Has it been merged, too?
bridgman: it has been merged into 2.6.30 though
edt: hd3300 (from amd 790gx)
edt: mattst88 what is the master branch and is development of drm for r6xx-r7xx now happening their?
mattst88: I think so yes. It's located here, http://cgit.freedesktop.org/xorg/driver/xf86-video-ati/
edt: cloning the above url fails
bridgman: you want master for -ati, but the 6xx-7xx branch for drm (or drm-next, or...)
mattst88: edt, of course it does. that's the web url
mattst88: git clone git://anongit.freedesktop.org/xorg/driver/xf86-video-ati
edt: which is what I am using for the ati part
edt: now I just have to figure out how to report problems (eg scrolling up in konqueror puts black lines across the window)
edt: thanks - restarting X
EruditeHermit: MostAwesomeDude: how goes the gallium on radeon?
spstarr: heh, I usually ask that ;)
bridgman: we probably need some kind of "channel header of the day"
bridgman: MostAwesomeDude; working on fragment shaders, remember I'm doing this in my spare time
bridgman: bridgman; still in IP review
bridgman: airlied; yes we already have kernel modesetting
spstarr: glisse: no, newttm isn't ready yet
bridgman: ah yes
DanaG: wait, did you just tab-complete your own name? =þ
bridgman: moi ?
bridgman: I don't even know how to do that ;)
DanaG: (09:08:17 PM) bridgman: bridgman; still in IP review
bridgman: ah yes...
airlied: bridgman: btw technically not just IGP have no-tcl, M6 and RN50 :)
DanaG: Oh yeah, what is "RN50"? is that the "ES1000" chip?
DanaG: I'd also wondered... FireMV... what can you do with that? Anything? I've never seen such a board in person.
airlied: yeah rn50 is the server chip
airlied: I think FireMV is just two chips one board.
DanaG: oh yeah, I know now AMD does stuff with Linux, and so does Novell, I've heard... I'm curious what, if anything, HP does.