airlied: wonders what mozilla is doing with so much exaGetImage
redeeman: sometimes the only thing more dangoures than a question, is an answer!
redeeman: :)
marcheu: airlied: renders the widgets ?
airlied: yeah its a pain if I don't migrate them properly :)
osiris__: MrCooper: why didn't you(TG) tell what new gallium driver you're creating? are you waiting for some IP clarification? maybe driver will not be released to comunity? or are you just trying to surprise us with some mind blowing, super fast driver?
marcheu: I hope it is a radeon gallium driver :)
z3ro: marcheu: given up on nvidia? ;)
loswillios: heh, would be great
marcheu: z3ro: I'm just hoping you guys catch up one day :)
loswillios: that'd probably mean xmvc too
z3ro: hehe :)
MrCooper: osiris__: I don't know, but I'd guess it's because we aren't allowed by the customer/contract to talk about it yet
osiris__: MrCooper: any ETA when you will be allowed to talk about it?
MrCooper: I have no idea
marcheu: I place my bets on a via driver :)
MrCooper: sounds like somebody should run a pool :)
spstarr_work: MrCooper: oh neat
spstarr_work: MrCooper: so a customer is having TG develop a (radeon) gallium3d driver :)
MrCooper: if you say so
spstarr_work: it could be via
MrCooper: nobody else did AFAICT
spstarr_work: though, having a working gallium3d driver is good for a template
jcristau: nouveau doesn't count?
Honk: he said "working" ;p
spstarr_work: hehe
marcheu: jcristau: also i915/965
marcheu: and cell
MrCooper: the softpipe driver should work
spstarr_work: airlied: I will try your new code if it goes into koji kernel
spstarr_work: oh
spstarr_work: its already there :)
spstarr_work: .321
C10uD: @all who heard about my problem with radeon(hd) drivers about getting black screen for a while after launching a new app
C10uD: logs seem to confirm that is due to gtk apps
C10uD: and the driver probing which screen is in use
C10uD: i wonder if there's a way to stop this from happening
C10uD: i'm using ubuntu intrepid for anyone wondering program versions, btw
mmp: osiris__: hi :)
mmp: any RS600 code to test? :)
ghepeu: what kind of gpu crash/lockup/crazy problem can make my computer reboot (after a few seconds or almost instantly)?
bobbens: computer reboot? faulty PSU
bobbens: only reboots I've had were because of faulty PSU + damage cpu heatsink fan
bobbens: said problems also caused gcc to failure randomly
bobbens: while radeon can hardlock the driver, it's never broughten my system down nor rebooted it
ghepeu: no, no, I'm almost sure it was a cpu problem.
ghepeu: It manifested twice after I upgraded to mesa 7.1/xserver 1.5
ghepeu: after more than 50 days without any single problem
chithead: do you have reboot on kernel panic enabled?
ghepeu: cat /proc/sys/kernel/panic
ghepeu: 0
ghepeu: also, there was a reproducible lockup with celestia that sometime caused the pc to reboot after a few seconds
osiris__: mmp: hi
osiris__: mmp: it looks like the RS600 has the same MC as R6xx
osiris__: and AMD is going to release some docs about it soon
osiris__: mmp: so we just have to wait, because I'm out of ideas
MostAwesomeDude: My guess is that TG's doing a D3D frontend. :3
z3ro: ghepeu: btw, I've seen lockups where the computer would reboot. both instant and after a few seconds.
z3ro: but I don't remember how they happened now, and I never tracked down the cause.
z3ro: and it could have been me giving the card screwed up vertices...
z3ro: last time I checked, extruding vertices to infinity on the CPU, then giving them to the GPU gives a nice lockup.
z3ro: although iirc this actually works on fglrx... so it might be worth checking out again and see if it's still a problem.
mmp: osiris__: ok; but.. wait for docs?
osiris__: yes
osiris__: mmp: I'm almost sure, that when these docs are out we will be able to make rs600 work in few hours
z3ro: osiris__: have you looked at the r6xx code in the DRM? it had some MC setup stuff in there.
z3ro: but I guess the rs600 might be some crazy weird hardware.
mmp: osiris__: okay, I'll be idling here and waiting for my time to come ;)
osiris__: z3ro: hmm, never looked at the r6xx docs. will check this out
z3ro: well we only have the ISA docs for r6xx so far... but there is some code in the r6xx-support branch of the DRM.
z3ro: it *looks* like enough to get the MC setup, but I only really looked at the GART stuff to get revenge working.
spstarr_work: MostAwesomeDude: that would be possible
z3ro: so it's possible it's missing some MC init stuff (but it looks pretty complete to me)
z3ro: MostAwesomeDude: btw, a d3d frontend sounds unlikely... who would fund that?
otaylor: z3ro: since when has that been the question for open source :-)
MostAwesomeDude: z3ro: Same people who fund Wine? I dunno.
z3ro: otaylor: well, TG is being contracted by a company for this, so someones paying for it.
otaylor: z3ro: It may be unlikley that TG will write a d3d frontend, yes.
otaylor: z3ro: Though I'm not sure... wine and winelib have gotten some serious corporate support at times, so it's quite possible someone *would* pay
z3ro: hmm yeah. I guess it's possible.
otaylor: (I did jump in onthe conversation, so I don't have a lot of context, I may be arguing against something you aren't saying :-)
z3ro: no, you got the point. :)
MostAwesomeDude: I dunno. If it's possible, then somebody will eventually do it.
z3ro: hmm, spyglass looks really cool for dumping out gl calls.
z3ro: I'm interested to see if I can reproduce that infinite-verts bug again.
glisse: there was somethings about d3d in Keith talks at xds
glisse: can't remember i wasn't following closely
osiris__: MostAwesomeDude: have you tried already bicubic on r300?
MostAwesomeDude: osiris__: Yeah, I get a nice kind of checkerboard.
MostAwesomeDude: Changes depending on pixel stack, like you said.
MostAwesomeDude: But I can't find a magic combo that makes it perfectly work.
osiris__: MostAwesomeDude: I wonder why would output change if we set pixel stack size to larger then we need
MostAwesomeDude: osiris__: I think there's something funky with the output from the shader analyzer.
osiris__: MostAwesomeDude: it could be, because I can see no changes when I set different constants
z3ro: MostAwesomeDude: noone got that shader analyzer working on wine, right?
MostAwesomeDude: osiris__: Not to mention that the swizzles on the texs look slightly off.
MostAwesomeDude: z3ro: I've tried. It requires DirectX 9 for the PS 3.0/GLSL stuff.
MostAwesomeDude: And we can't just drop in native DLLs.
osiris__: MostAwesomeDude: I could try writing not optimized shader if someone gave me the fp
MostAwesomeDude: osiris__: I've done it before; lemme see if I've got it in my logs.
z3ro: MostAwesomeDude: hmm too bad. sounds like a useful tool.
z3ro: but I'm probably too lazy to setup a full VM environment.
MostAwesomeDude: z3ro: Yeah, I don't own Windows, and I'd really like to not have to bother with it.
MostAwesomeDude: Besides, it can't compile arb_f_p, only GLSL and HLSL, so its utility for me is kinda limited ATM.
z3ro: maybe we could ask bridgman to kick whoever writes that tool into making a linux version.
z3ro: although if it's hooked into dx, then it would probably be a pain.
MostAwesomeDude: Well, yeah, I think it uses the DX compiler.
ghepeu: z3ro, thank you, at least now I know that the reboots are not due to faulty hardware
ghepeu: somebody will fix the problem, sooner or later
ghepeu: if it can help, yesterday the computer rebooted while I was testing textured xv with mplayer -benchmark
z3ro: I never had lockups/reboots from mplayer (at least as far as I remember)
z3ro: only during 3d rendering
ghepeu: me neither
ghepeu: but textured xv use the 3d engine, I think
z3ro: well, I'm going to see if I can reproduce the lockup/reboot I got a while ago with shadow volume verts (extruding them on the CPU rather than GPU)
z3ro: iirc this would work on fglrx, but die on r300... so I should be able to get a trace from fglrx and replay it on r300
z3ro: then see what happens.
MostAwesomeDude: osiris__: 'k, found the stuff in my logs. One sec.
z3ro: heh hopefully I can remember which card I was using at the time.
z3ro: anyway, going to go watch dr who while stuff compiles.
MostAwesomeDude: osiris__: http://pastebin.com/m3f95590b is what's currently in the comments.
MostAwesomeDude: http://pastebin.com/m156f71d7 is using Mesa to compile the shader from the r3xx comments.
ghepeu: what matters to me now is that yes, a cpu lockup can cause a machine reboot. the origin is secondary, I can keep using xserver 1.4.2.
ghepeu: oh, by the way, during my (brief) time with xserver 1.5.0 I noticed that x11perf -aa10text dropped from ~220k char/s to ~140k char/s
ghepeu: with exa hw render acceleration on a rv370 pci-e
osiris__: MostAwesomeDude: in these mesa debug log tex[0] is video image or bicubic helper matrix?
MostAwesomeDude: osiris__: tex[0] is the image, and tex[1] is the helper.
MostAwesomeDude: Also, the const was split in order to avoid the swizzle.
osiris__: MostAwesomeDude: how it was split? (width, 0,0,0) and (0, height, 0, 0) ?
MostAwesomeDude: No, I basically did the swizzle. (width, 0, width, 0) and (0, height, 0, height) IIRC.
osiris__: glisse: are pixel stack entries zeroed at fp start?
airlied: osiris__: the r6xx drm should have enough to setup the VM
airlied: and MC
glisse: osiris__: i think their content is undetermined if nothings is routed to them
spstarr_work: airlied: ping
airlied: spstarr_work: pong
spstarr_work: airlied: will try new kernel when i get home in 50 mins
osiris__: airlied: yeah, agd5f said rs600 mc is similar to one in r600, but looking at r600_support branch and fglrx dumps from rs600 they don't look similar to me
spstarr_work: airlied: should I try kms on the r6xx? or no kms for r6xxx yet?
airlied: no kms yet.
spstarr_work: ok
airlied: the code is there, just not switched on or tested.
spstarr_work: perhaps the new code you added will get the rv350 to work
osiris__: MostAwesomeDude, airlied, glisse: could you review my FP optimizations http://pastebin.com/m1127770b ? it's bicubic FP for R300 hardware
MostAwesomeDude: osiris__: Thanks, readin'. :3
MostAwesomeDude: osiris__: Looks pretty good. After I finish my r6xx experiment, I'll take a look.
airlied: spstarr_desk: btw your rv350 is AGP, did I ask what agp chipset?
MostAwesomeDude: airlied: I'm starting to see how the r6xx stuff works in DRM. Looks like there's independent r600 files, should those be merged in?
airlied: MostAwesomeDude: nope.
airlied: some bits may need to be but mostly its a very different chip setup.
airlied: for modesetting you might need some bits from there.
airlied: you could merge the whole lot to start off I suppose
MostAwesomeDude: So r600_cp stays separate. Same thing with r600_microcode?
airlied: yes.. the CP and microcode are not enough alike to merge them
MostAwesomeDude: Okay.
MostAwesomeDude: airlied: fb location works now. I know it does, because I lose video when I modprobe radeon, and it doesn't come back. :3
MostAwesomeDude: Hmm, I should ssh in and get a copy of dmesg. One sec.
airlied: well you can lose it in a number of ways :)
MostAwesomeDude: airlied: My guess is that fb location is written, and then something happens that we didn't write code for yet. :3
airlied: well the console is all sw rendered, and if you don't try and start the CP it should be possible to get it to work
MostAwesomeDude: Hm, I don't know if I'm trying to start the CP. I don't think so?
airlied: there is probably quite a bit of code in the gem startup that needs to be not run on r600
airlied: like allocating things in GART memory would be failure.
spstarr_desk: airlied: ping
spstarr_desk: airlied: no go
spstarr_desk: but
spstarr_desk: it doesn't show garbled boxes anymore it just turns off backlight, tries to post video, but fails.. the machine is still booting
spstarr_desk: after starting login as root without seeing screen and run init 5 .. X is trying to start now...
spstarr_desk: but we still dont have any video posted
airlied: spstarr_desk: I asked about the AGP bridge btw.. which one is it?
MostAwesomeDude: airlied: Well, do we replace that with r600-only code, or do we just not do it?
airlied: MostAwesomeDude: you could just not do it for now
airlied: MostAwesomeDude: considering we have no accel on r600
spstarr_desk: airlied: lemme get this info for you
spstarr_desk: airlied: the last time i told you about the r300 on this AMD machine im on now but we had video posting (just some instabilities though with dpms displaying display and it not returning)
MostAwesomeDude: airlied: Okay. Well, I'll look into various parts of it.
spstarr_desk: airlied: the AGP bridge on the Thinkpad is: Intel Corporation 82855PM Processor to AGP Controller
airlied: spstarr_desk: I just remember one dmesg from you I think where the agp bind call failed
spstarr_desk: looking at dmesg on laptop
airlied: it was when debug was enabled
MostAwesomeDude: airlied: http://pastebin.ca/1199429
spstarr_desk: [ 1.065770] agpgart-intel 0000:00:00.0: Intel 855PM Chipset
spstarr_desk: [ 1.080128] agpgart-intel 0000:00:00.0: AGP aperture is 256M @ 0xd0000000
spstarr_desk: airlied: which debug option, i'll reboot the laptop
MostAwesomeDude: I can see a number of issues here.
MostAwesomeDude: GART setup, no r6xx microcode, etc.
spstarr_desk: no errors in log except;
spstarr_desk: [ 1.746181] i2c-adapter i2c-0: unable to read EDID block.
spstarr_desk: [ 1.789051] pci 0000:01:00.0: VGA-1: no EDID data
spstarr_desk: but thats fine there's nothing attached
spstarr_desk: oh drm debug=1
airlied: spstarr_desk: yup.
airlied: MostAwesomeDude: none of that should be necessary to get a picture though
airlied: MostAwesomeDude: really we just need the same codepaths as the 2D driver uses.
airlied: and a small amount of memory controller setup
spstarr_desk: odd now radeon pulls in i2c kernel module
spstarr_desk: can't unload it
spstarr_desk: oh yeah, reboot with nomodeset then drm debug=1 ?
airlied: yup.
spstarr_desk: sec
spstarr_desk: ok did
spstarr_desk: debug coming
airlied: if it doesn't fail on agp bind then its not the bug I'm looking for :)
spstarr_desk: airlied: http://www.sh0n.net/spstarr/radeon-rv350.dump
spstarr_desk: there's no display though from that
spstarr_desk: though that is much different then the previous fails
spstarr_desk: it looks very close to video posting
groo_: hi/2 all
MostAwesomeDude: airlied: Is doing the CP just out of the question at the moment? Really, I don't know if it's possible to do this on the modesetting-gem branch without it. http://pastebin.ca/1199444
MostAwesomeDude: OTOH, I could just be silly.
airlied: MostAwesomeDude: the modesetting code doesn't need it, you need to avoid all the accel codepaths.
airlied: so all the gart allocations, the table allocs, the buf ad
airlied: you should only add one memory area for the VRAM
MostAwesomeDude: Is there a convenient switch that I missed somewhere, or do we just have to set if >= CHIP_R600 at each of the places?
spstarr_desk: airlied: is anything in that dump catch your eye?
groo_: ppl, im having a very strange crash with xorg 1.5 and kde 4.1
airlied: spstarr_desk: it all looks fine... can you plug a VGA monitor in and see if it comes up?
spstarr_desk: good thing to have a small 4 port KVM :)
groo_: if i log onto kde 4.1 using vanilla .kde4 X dies on me, i have to run the kde 4.1 systemsettings from a kde3 and enable opengl for X to live
groo_: aparently the compositing is broken per se
groo_: anyone is having this behaviour?
spstarr_desk: airlied: nope
airlied: spstarr_desk: even from boot.. dang..
spstarr_desk: airlied: though with the LVDS i see it go black when the power saving kicks in, but if i press a key the backlight comes on
spstarr_desk: oh
spstarr_desk: lemme try with booting up
spstarr_desk: didn't try with booting it up..
spstarr_desk: YES!
spstarr_desk: airlied: I see the big lock icon on the VGA screen
airlied: nice at least its not total failure then
airlied: just LVDS failure
spstarr_desk: yes
spstarr_desk: we're good on VGA-0
airlied: need to talk to agd5f about the LVDS powerup sequence.
airlied: he changed it from the DDX one I think
spstarr_desk: very close now :)
groo_: seeya al; later
spstarr_desk: uh oh
spstarr_desk: the laptop hard drive isn't spinning up
spstarr_desk: YAY!!!!
spstarr_desk: that last forceful poweroff wasn't good
chithead: nfs root + spun down hdd during kernel hacking ftw
spstarr_desk: nope the disk is ok
chithead: it survived... this time
spstarr_desk: my VGA plugin experience caused the IBM BIOS some failure with keyboard
spstarr_desk: i think
spstarr_desk: yeah its ok
spstarr_desk: but the disk is from 2004
spstarr_desk: a backup is in order
spstarr_desk: seems i had a stuck key and the machine refused to boot
spstarr_desk: (it showed a bios error then i powered off, then unplugged the USB thing) then it still refused to boot, until i pressed some key(s) maybe something was stuck
MostAwesomeDude: airlied: Okay, so http://pastebin.ca/1199498 appears to not do anything wrong, but it also doesn't do stuff right.
MostAwesomeDude: I commented out the GEM init and the CP init, so it's only doing radeon_modeset
MostAwesomeDude: *radeon_modeset_init, or whatever it's called. I guess it might need *more* stuff than that?
MostAwesomeDude: Dinner, back later.
MostAwesomeDude: Back, lawl.
rx__: you've got gem working?
cxo: Do any of you guys get a black screen for a sec, when an opengl window resizes?
cxo: note _window_ and not fullscreen request
spstarr: hmm
spstarr: glxgears crashes
spstarr: oh
spstarr: airlied:
spstarr: libGL error: drmMap of framebuffer failed (Invalid argument)
spstarr: libGL error: reverting to software direct rendering
MostAwesomeDude: rx__: Well, I've got modesetting-gem working on the r4xx and r5xx.
cxo: yeah for me too, but i just get a Segmentation fault
spstarr: glxinfo with LIBGL_DEBUG=debug
MostAwesomeDude: Haven't tested 3D yet, but EXA works.
spstarr: cxo: ok so something blew up
spstarr: cxo: Fedora?
cxo: yes, but i recompiled everything even X, from git
cxo: i guess glx-utils is from fedora
cxo: ah, but even my mesa-git's demos dont work
cxo: brb need to logoff and relogin, stupid linux cant use new groups untill you relogin
cxo: or ie initgroups(), which is usually only called by login processes
airlied: spstarr: you mesa 7.2? sw rendering crashes gears alright I've heard
spstarr: it was working yesterday
spstarr: but i have a new kernel...
spstarr: 7.2 yes
MostAwesomeDude: airlied: So, I removed the GEM init, and the CP init. Is there perhaps something *extra* needed?
airlied: well you might need bits of those I'm not 100% sure which bits.
jcristau: cxo: newgrp is useful.
cxo: yeah but doesnt help with X apps
MostAwesomeDude: airlied: Perhaps we should just leave it until the r6xx docs become available, and we can go ahead and start doing DRI?
cxo: even su - user, is fine, but you need to respawn Xsession
MostAwesomeDude: Perhaps I should figure out HTF bufmgr works?
airlied: MostAwesomeDude: `you don't need docs to get modesetting going though
jcristau: cxo: fair enough
MostAwesomeDude: airlied: Yeah, but OTOH...oh, wait.
airlied: so you need the start of gem_mm_init up the gart _init
MostAwesomeDude: At some point, I suppose, we'll need modesetting in KMS on r6xx to work.
airlied: then you can skip to the mm_enabled=true
MostAwesomeDude: So I might as well do it now.
MostAwesomeDude: Okay, I'm lookin' now.
airlied: then for modeset_cp_init you can probably do none of it.
airlied: and skip the irq install
MostAwesomeDude: We don't need IRQ?
MostAwesomeDude: Oh, wait, IRQ is for CP only?
airlied: r600 irqs are different
MostAwesomeDude: Oh. 'k.
airlied: the irq controller regs aren't the same at all
MostAwesomeDude: And I take it that we haven't been given them? Or at least, it doesn't matter for this?
airlied: it doesn't matter for this
MostAwesomeDude: 'k.
spstarr: MostAwesomeDude: I can test
MostAwesomeDude: Do I ask too many questions? Am I just annoying you? :3
airlied: hehe if you get it working you can ask questions :)
airlied: if you don't get it working I'll stop answering :-P
MostAwesomeDude: Fair enough.
MostAwesomeDude: I've never really messed with DRM guts before, so yeah.
spstarr: still wants to work on theatre support for kernel.. but not yet
airlied: MostAwesomeDude: most likely issue is the fb location and the << 16 vs << 24 stuff
spstarr: I still need to wrap my head around hardware guts
MostAwesomeDude: Hm. I got the fb location, or at least, I got the version from the r6xx-support branch.
airlied: MostAwesomeDude: yup just make sure its being used properly everywhere.
airlied: there may be some code in modesetting that doesn't do the right thingh
airlied: it might still do << 24
airlied: and in some places << 16 might be right :)
airlied: confused yet? :)
MostAwesomeDude: Trying to find the right place in the code.
MostAwesomeDude: So the bo_init_mm stuff should be alright?
airlied: as I said skip from the gart_init to the end of function
airlied: just setting up VRAM mm
airlied: don't need a GART mm yet
airlied: you could set it up but probably a waste at this point
MostAwesomeDude: Makes sense.
MostAwesomeDude: I don't know *why* the GART and CP are different/make things not work, as long as I know that right now, they're not needed. :3
airlied: well the r600 is completely different chip layout..
airlied: so the code hits registers in the wrong place
MostAwesomeDude: Okay, so [drm:drm_bo_init_mm] *ERROR* Memory manager already initialized for type 0
cxo: hits registers in the wrong place
MostAwesomeDude: Although I feel that's not the problem.
airlied: ignore that most likely..
MostAwesomeDude: Well, let's look at fb location. Um, why is it shifted 24?
airlied: MostAwesomeDude: the r600 has a 40-bit internal memory bus
airlied: MostAwesomeDude: so it uses 40-bit instead or 32-bit addresses, so needs 8 more bits
MostAwesomeDude: And 16 + 24 = 40.
MostAwesomeDude: I see.
MostAwesomeDude: XD, my math is good, but my brain is fried. Sorry, last final tomorrow. B- or better means I go to university.
dmb: 16 + 24 = 0
MostAwesomeDude: dmb: It does?
dmb: yup
MostAwesomeDude: Oh.
cxo: who taught you math
MostAwesomeDude: It's a history final, BTW.
dmb: lol
MostAwesomeDude: But nice try.
cxo: MostAwesomeDude, did you watch that video about Gallium
MostAwesomeDude: cxo: No?
MostAwesomeDude: Must have missed it.
cxo: The speaker said in it that, if you _even_ look at the driver code, you are a genius
MostAwesomeDude: XD
cxo: it was a very good video
cxo: it covered all of the gallium arch and current arch
MostAwesomeDude: I'm a genius, sure, but GPU code makes me feel like an idiot sometimes.
cxo: watch -> http://stecchino.blip.tv/file/1181861/ <- now
spstarr: ya
spstarr: presented at aKadamy 2008
MostAwesomeDude: Okay, so for r6xx, fb
MostAwesomeDude: fb_location should be read and written << 16, or << 24?
airlied: << 24
cxo: i thought you got a bunch of r700s
MostAwesomeDude: cxo: An r6xx and an r7xx.
cxo: so how come you are fighting with the driver, i thought the novel guys are writing it?
airlied: cxo: we are crazy.
cxo: reinvent the wheel each day
MostAwesomeDude: cxo: Because I'm trying to get GEM + KMS going on r6xx. They're just trying to get 3D going.
airlied: every other day, I spend the days in between making round objects
cxo: i thought you need GEM or some kind of memory management for 3d
airlied: no we have 3D on all the other chips without memory management
MostAwesomeDude: cxo: Well, for advanced higher-level stuff, yes.
airlied: you need memory management for anything above GL1.3 really
MostAwesomeDude: airlied: Including occlusion queries?
cxo: what does that mean in terms of being able to play games with wine
MostAwesomeDude: Also we can get OGL 1.4 w/o the memory manager. :3
MostAwesomeDude: I just need to find a way to make fog work.
airlied: MostAwesomeDude: ah 1.4 then.. we should be able to do OQ now.
MostAwesomeDude: Yeah, OQ are a 1.5 feature.
airlied: cxo: depends on wyhat the game needs.
airlied: if things need fbos you need a memory manager
cxo: all of opengl2 i'm guessing
MostAwesomeDude: cxo: Well, not all of it. GLSL doesn't need memory management.
MostAwesomeDude: Technically, you could host shader objects in VRAM, although I don't know of any cards that could *do* anything with it.
cxo: lame
cxo: remind me to take over the world tomorrow
cxo: i'll sort it all out
airlied: realises my buffer move code is possibly made out of fail
MostAwesomeDude: airlied: I got an oops
MostAwesomeDude: But then again, I think it was 'cause I did "modprobe -r radeon; modprobe radeon modeset=1"
MostAwesomeDude: I forgot to tell it to modeset at first. :3
cxo: MostAwesomeDude, talk to Britney Spears about that
MostAwesomeDude: Anyway, there was only one spot where the code didn't have the if(r6xx) switch for fb_location.
MostAwesomeDude: So I'm gonna reboot and try again.
airlied: hmm migrating the front buffer while Im using it == bad fail event horizon
MostAwesomeDude: Yeah.
MostAwesomeDude: So, IIUC, the back buffer(s) are mapped to the front buffer using either the 3D engine, or some kind of blitter, and then the front buffer is copied to the frame buffer during vsync?
MostAwesomeDude: Or do I have it all wrong?
airlied: its in transition :)
airlied: currently with DRI1 we have one front and one back buffer, shared amongst everyone
airlied: and whenever a client asks its back gets blitted to the front
airlied: using cliprects so only its bits get sent
airlied: page flipping takes it a step further, when there is one 3D app, it just sets the crtc to scan out the back instead of the front and alternates
MostAwesomeDude: Wow, I can see how page flipping would be awesome for double buffering.
airlied: yup it saves a lot of copying in the single app case
airlied: however when you have 2D rendering to the front buffer you get fail.
airlied: so composite pushes 2D rendering to private pixmaps...
airlied: then DRI2 will push 3D rendering to private backbuffers
airlied: and redirected front buffers
airlied: and only the compositing manager will draw to the front buffer
MostAwesomeDude: Ah.
MostAwesomeDude: So compositing managers grab pixmaps from a variety of private backbuffers and mix them into the front buffer?
MostAwesomeDude: Or something kinda like that?
airlied: yup.. they grab all the private pixmaps/buffers into the compositing managers backbuffer..
airlied: and thne either flip or copy that to the front buffer
MostAwesomeDude: That sounds like equal opportunity awesome and fail.
MostAwesomeDude: ...And it's Spanish time in #nouveau.
airlied: what it most definitely is chew VRAM.
MostAwesomeDude: But OTOH VRAM is cheap and we might as well use it if it's there.
MostAwesomeDude: So, as far as dri-bufmgr goes. How do we make it faster?
airlied: write faster code :)
MostAwesomeDude: XD
MostAwesomeDude: I dunno. I think I'll pull it on the Debian box and pop in the r4xx and see what's up.
MostAwesomeDude: I remember nha mentioning that it was slower than non-bufmgr, is that just because we're not handling state well?
airlied: yup..
airlied: the texture handling is suboptimal.
airlied: write a GEM backend might make it a lot nicer in parts also.
airlied: I have GEM emulating the old school backend but its not very stable
MostAwesomeDude: Hm, isn't that up to Mesa core, or do we have to explicitly start using GEM to reap the benefits?
airlied: core doesn't do any of that
airlied: the bufmgr is per driver.
cxo: Is there a channel for gallium?
airlied: and you write a driver specifc backend
airlied: in our case we have a bufmgr that backs onto old memory management code.
airlied: we really need to optimuse that one a bit better.
airlied: then write a new one onto new memory manager code
MostAwesomeDude: Ah.
MostAwesomeDude: Well, I mean, I don't know too much about GEM, but after reading the ioctl summary, isn't it basically "create tex", "destroy tex" as far as Mesa goes?
terracon: I just watched that talk by Zack Rusin, excellent link
airlied: MostAwesomeDude: no its memory objects at the bufmgr level.
airlied: you have to put textures into memory object and deal with mipmapping
airlied: its gets messy quick.. hence why nha got bogged down in it
MostAwesomeDude: Oh, wow.
MostAwesomeDude: That sounds...painful.
airlied: ouch my DMA is going badly wrong..
airlied: I'm getting random memory corruption after I blit something around
cxo: at least its not your DNA
cxo: and that my friends is the end of my dry humor for tonite, i bid you all vertex shader dreams
MostAwesomeDude: Hm. Okay. Sleep now, code after finals.