mmp: quit
mmp: sorry:-)
airlied: benh: oh I'll look at the r600 docs when I get a chance for swappers stuff
benh: airlied: thanks ! I'm a bit swamped at the moment
benh: airlied: I hope to get a bit of time for that by next month, though with KS etc.. .it will not be trivial
glisse: benh: btw wehre is KS ?
glisse: same place as xds ?
glisse: i hope so you can pay me beer :)
benh: portland, OR
glisse: stupid linux foundation
benh: hehe
glisse: how can i get free beer then
jcristau: glisse: maybe LF can sponsor your flight to portland :)
LeastAwesomeDude: Wait a sec, what's going down in Portland?
LeastAwesomeDude: I thought XDS was in Edinburgh?
LeastAwesomeDude: I mean, I can make it to Portland, that's just a short drive for me.
lkro: LeastAwesomeDude: Kernel Summit 2008.
LeastAwesomeDude: lkro: Ah.
LeastAwesomeDude: Not related to Linux Plumbers?
lkro: Well, dates are indeed close. So probably related somehow.
LeastAwesomeDude: Mm, not necessarily, it's not surprising that kernel meetings happen at the home of kernel.org around the time that school starts. :3
DeX77: Hi
DeX77: anything known about periodic (3-5 Seconds) hickups while using fglrx (8.6 or 8.7) with HD 4850 (and NOT while using radeon)
mlankhorst: DeX77: topic
DeX77: did read it.. just thought some of you know if this is driver related at all
DeX77: the OS driver doesnt seem to register a interrupt, so I think it maybee interrupt related
mlankhorst: DeX77: topic
DeX77: so I will change my question: does the os driver use interrupts?
si0n4e: hi guys, i have a radeon x1950 and i am trying to enable the dri but i get an error message i can not find any info about with google "unknown chip id 0x7244, can't guess." any pointers?
adamk: si0n4e, You get that when running 3D apps? If so, your version of Mesa is too old.
si0n4e: adamk: i get that when i libgl_debug=verbose glxinfo
adamk: Right, when running 3D apps.
adamk: So your version of Mesa is too old.
si0n4e: would you happen to know which version of mesa is the minimum required to enable it
si0n4e: currently i have libgl1-mesa-dri_7.0.3
nha: si0n4e: at the very least one of the Mesa 7.1 release candidates
si0n4e: thanks a lot for clearing that out for me
osiris__: agd5f: ok, I finally managed to compile everything, but I don't know actually if radeon ms driver uses radeon drm module for mode setting. how to check this? can't find anything in xorg log
agd5f: osiris__: modprobe radeon modeset=1
osiris__: aah
agd5f: also make sure you load fbcon
agd5f: modeprobe drm; modeprobe fbcon; modeprobe raeon modeset=1
osiris__: agd5f: lots of i2c-adapter i2c-0: unable to read EDID block. and X doesn't start
osiris__: [drm:drm_ttm_bind] *ERROR* Couldn't bind backend.
osiris__: [ 1132.389241] [drm:drm_buffer_object_validate] *ERROR* Failed moving buffer.
osiris__: [ 1132.389246] [drm:drm_unlocked_ioctl] *ERROR* ret = 5d -22
agd5f: osiris__: make sure you loaded fbcon before you loaded radeon
osiris__: agd5f: I did
agd5f: osiris__: what card?
osiris__: rv380
agd5f: pcie or agp or pci?
osiris__: pcie
agd5f: osiris__: are you using airlied's radeon-gem-ms xf86-video-ati branch?
osiris__: yes
agd5f: osiris__: pastebin your kernel log and xlog?
agd5f: I haven't actually tested an r3xx board yet
osiris__: agd5f: kernel: http://pastebin.com/m1c2df586 xorg: http://pastebin.com/m61b6ff24
agd5f: osiris__: did you build a new drm module as well?
osiris__: agd5f: yeap
agd5f: did oyu unload the old drm and re-run depmod?
agd5f: depmod -a
osiris__: agd5f: scroll down
osiris__: line 1020
agd5f: osiris__: can you try with drm debugging enabled? modprobe drm debug=1
osiris__: ok
agd5f: osiris___away: Just tried an rv380 board here and it works fine
airlied: its fbcon problem, disable vesafb
airlied: or whatever is getting fb0
osiris__: airlied: will try
osiris__: agd5f: if it's still needed, kernel log with drm debug: http://pastebin.com/m3e74e769
agd5f: osiris__: looks like the fb issue airlied pointed out
osiris__: airlied/agd5f: so I should disable building support for all frame buffer devices?
agd5f: osiris__: either that or make sure they don't get loaded
osiris__: agd5f: they're built in, so I have to recompile the kernel
agd5f: yup
airlied: osiris__: you have vesafb built in?
osiris__: airlied: yeah, and VGA16 too
airlied: I think you can boot with some option to diable them
airlied: or unbind them before loading
osiris__: already rebuild the kernel
airlied: uggh modesetting on the rn50.. it starts, but writeback is broken..
airlied: broken on my r100 also ..
airlied: ah need the mc setup code now.
MostAwesomeDude: Whoo, compile warnings gone. Let's see what happens.
MostAwesomeDude: Okay, I yield. It's not finding symbols even though I thought I had it right.
MostAwesomeDude: I'll wait.
airlied: MostAwesomeDude: you need to modprobe things by hand
airlied: lots of things.
MostAwesomeDude: airlied: It's not finding shmem_file_setup, or whatever that symbol is.
airlied: MostAwesomeDude: I thougt you exported it
MostAwesomeDude: airlied: Yeah, I did.
MostAwesomeDude: Generally not a good sign.
MostAwesomeDude: I think there are thingys in linux/mm.c which I don't properly understand yet.
MostAwesomeDude: Not surprising; I've never had a patch accepted to the kernel yet. I must not be at that level yet.
airlied: MostAwesomeDude: you can justpull the queue from drm-rawhide if you are lazy.
airlied: git://git.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6.git
airlied: drm-rawhide branch
MostAwesomeDude: Mm, I'll wait. I'm not that lazy.
MostAwesomeDude: Or, no, wait, does it make me lazier to wait?
MostAwesomeDude: Ag.
MostAwesomeDude: At any rate, I can't help this nagging feeling that there was some other piece of code I needed to work on.
rbrett: MostAwesomeDude: You could implement a lancos video filter? Not sure how beneficial it would be though.
MostAwesomeDude: rbrett: Looked into it. Lanczos wouldn't be possible without more of that crazy bilinear-assisted math.
MostAwesomeDude: On the plus side, we *do* have HW sine.
airlied: MostAwesomeDude: wheres my GLSL already ;-)
MostAwesomeDude: But it'd only be possible on r5xx+, probably.
MostAwesomeDude: airlied: Oh, that's right! I was gonna look into GLSL!
MostAwesomeDude: Heh.
RTFM_FTW: mmm GLSL should be viable for you guys on R3xx, R4xx, R5xx
MostAwesomeDude: RTFM_FTW: I still don't understand how conditionals are supposed to be done on pre-r5xx. Are we supposed to just refuse the program with a GL error if it's got flow control?
MostAwesomeDude: IIRC there's not predication of any kind on r3xx...
RTFM_FTW: well you aren't going to handle dynamic control flow in HW so those will have to be thrown onto a SW fallback of some sort
RTFM_FTW: which the GLSL specification allows for
MostAwesomeDude: I'll have to re-read the GLSL specs.
MostAwesomeDude: Looks to me like most of the GLSL stuff is already in the opcodes, so it could just be adding some stuff to the FP compilers...
MostAwesomeDude: Gotta figure out how to do DDX and DDY, though.
RTFM_FTW: hardware versus software acceleration for a given language feature was purposely left as a open ended question
RTFM_FTW: having a good shader compiler helps with this stuff as well
MostAwesomeDude: Yeah, I really don't want to have to do any shader compiling in the DRI driver itself.
MostAwesomeDude: It'd be better to let Mesa do its thing, and then any optimizations could be done in the two-pass thing that nha's got set up.
MostAwesomeDude: Looking over the list here, though, most of the stuff's directly possible on r5xx HW.
RTFM_FTW: yep
MostAwesomeDude: Hm.
MostAwesomeDude: Okay, in my classic "fail" technique, I can't figure out how to enable GLSL.
MostAwesomeDude: Oh, wait.