dli: (==) RADEON(0): Backing store disabled
dli: (WW) RADEON(0): Direct rendering disabled
dli: with newest git version or drm, mesa, xf86-video-ati, I lost DRI
airlied: dli: wierd..
airlied: dli: look in the last place you had it :)
dli: airlied, not exactly, direct rendering: Yes
airlied: dli: did the drm load okay?
dli: radeon 134736 0
dli: not being used
airlied: no idea, xorg log should explain why
dli: (WW) RADEON(0): Direct rendering disabled
dli: (==) RADEON(0): Backing store disabled
airlied: it should say something before that.
airlied: like back up the log somewhere.
airlied: pastebin the log file
dli: airlied, Xorg.0.log http://pastebin.ca/1051737
airlied: dli: any in dmesg? is that master or powerplay branch?
dli: [drm] Initialized drm 1.1.0 20060810
dli: PCI: Setting latency timer of device 0000:01:00.0 to 64
dli: [drm] Initialized radeon 1.29.0 20080613 on minor 0
airlied: wierd, #
airlied: wierd, (II) RADEON(0): [dri] Visual configs initialized
airlied: #
airlied: (WW) RADEON(0): [drm] failed to enable new memory map
airlied: no idea why that could fail
airlied: looks like a possible 32/64 bit but we shouldn't have any more of those.
dli: airlied, let me try the previous commit
airlied: dli: oh go back one in the drm ioctl
dli: airlied, ok
airlied: dli: just revert the top commit.
airlied: dli: should be fixed.
dli: airlied, X is very sluggish now:( takes time to build
dli: airlied, yes, revert to 00f549bd5f40d9 fixed the problem
airlied: dli: try drm master now.
dli: airlied, ok
dli: airlied, yes, it's fixed in master now, also, fullscreen XV works
dmb: airlied, were those glisse lockup fixes pushed into drm?
dmb: also, how long before the drm git gets pushed into the linus tree?
airlied: dmb: some bits are pushed..
airlied: dmb: I pushed that broken patch before dli found it :)
airlied: dmb: so I've had to sneak the fix in.
airlied: not all the lockup fixes are gone upstream yet.. too much chance of regression
MostAwesomeDude: Evening.
MostAwesomeDude: Sorry for not being on all today; some stuff came up. Also I'll be up in Seattle all weekend, so Internet is "as-is".
dmb: MostAwesomeDude, your fired!
MostAwesomeDude: dmb: Oh man!
MostAwesomeDude: Guess I have to back to slacking around, not working, and writing code and music when I get bored.
MostAwesomeDude: :3
dmb: lol
hgb_: agd5f: It's still acting up. I also see problems now when I suddenly (no idea what caused it) fail to open display :0.0 (can't open new windows, etc)
hgb_: Then I went home for the day, and today I can open windows om :0.0 again!
hgb_: How odd.
MrCooper: what was the exact error?
MostAwesomeDude: agd5f: Okay, so I gather that kernel modesetting requires DDX AND kernel changes. I know the Intel driver has a thing where it will automatically detect a modesetting DRM and relenquish the reins; does radeon do the same thing or is it just a kind of hackish thing?
MrCooper: MostAwesomeDude: I don't think there's any such code for radeon yet
MrCooper: MostAwesomeDude: glisse started a new DDX driver for kernel modesetting
MostAwesomeDude: MrCooper: Oh, I have to use glisse's DDX too?
MostAwesomeDude: ...This could be complicated.
MostAwesomeDude: I don't know which piece of code to check out, pick up, study intently for two hours, and then give up on.
MrCooper: yeah
hgb_: MrCooper: Was that for me?
MrCooper: yes
hgb_: In that case:
hgb_: $ xterm
hgb_: No protocol specified
hgb_: xterm Xt error: Can't open display: :0.0
hgb_: MrCooper: I also see "flickering" every time I enter, exit or create a window. Looks like I get a very quick snapshot of the screen offsett by, say, half a screen left/right and up/down.
MrCooper: weird
hgb_: MrCooper: And the third issue is that I can move from Screen0 (left) to Screen1 (right), but not back again.
hgb_: I'm running dual-head on two screens (zaphod)
MrCooper: the third issue is unlikely due to the video driver
MostAwesomeDude: Arg, freakin' Gentoo blew away my GCC. I swear, this distro is more pain than it's worth.
hgb_: I have a small utility to move the pointer from one screen to the other. That works. I can't understand why using the mouse doesn't, but I agree, that doesn't sound like the video driver.
hgb: really doesn't want to go the way of the fglrc
hgb: fglrx
hgb: Or whatever it's called
MostAwesomeDude: Okay, so I'm about to reboot.
MostAwesomeDude: Once I do so, I will blow away nearly everything except /etc and /home, and start anew.
MostAwesomeDude: My question is: amd64 or i686?
MostAwesomeDude: ...Y'know what, stupid question, and off-topic. I'll just go amd64.
scarabeus: amd64 is ok on gentoo
scarabeus: just use testing
scarabeus: :]
MostAwesomeDude: scarabeus: Only as needed. :3
scarabeus: :]
MostAwesomeDude: BRB, reinstalling Linucks, lawl.
scarabeus: MostAwesomeDude: dont forget to install from testing install
scarabeus: aka 2k8
MostAwesomeDude: scarabeus: I know.
scarabeus: because there are really some pain in the as instaling from old one
scarabeus: ook
|moe|: good morning
|moe|: airlied: did you find the time to build a new kernel?
mcgreg: X crashed again when I wanted to start WoW :/
mcgreg: and again .. wtf
mcgreg: hmm and 3. time in row ..
mcgreg: hmm it seems to work if I start it in full screen mode , then switch to window .. but if I directly open it in windows mode X crashes
MostAwesomeDude: Back, lawl.
mcgreg: MostAwesomeDude: from your games/program list.. why would you want to use second life with wine? there is a linux version
MostAwesomeDude: mcgreg: Isn't it winelib? Or is there actually a fully native client?
MostAwesomeDude: I'm not really acquainted with the game...
mcgreg: as far as I know it is funlly linux native, even open source (I've heard)
MostAwesomeDude: Huh.
MostAwesomeDude: Well, if that's the case, I'll change it as soon as I'm back up.
MostAwesomeDude: (I'm on my tinderbox right now; my laptop'
MostAwesomeDude: laptop's rebuilding the base system.
MrCooper: yeah, otherwise I couldn't run it on my PowerBook :)
mcgreg: http://secondlifegrid.net/programs/open_source
mcgreg: MostAwesomeDude: I just registered to the second life world .. just to test if it works ;)
|moe|: does it?
mcgreg: I am still dowbnload in the client, it load incredibly fast with 85kb/s (it is 55mb)
|moe|: nice
mcgreg: I wonder if it will work at all
mcgreg: but in about 10 minutes I'll see
|moe|: waiting for your report
mcgreg: heh
MostAwesomeDude: mcgreg: Still working on the laptop. Good luck. :3
|moe|: do you run it on wine or is there a linux-client available?
mcgreg: linux client
mcgreg: the client is open source
|moe|: progressive ;-)
mcgreg: http://secondlifegrid.net/programs/open_source <---
|moe|: they want you to put your money into the linden-dollars instead
mcgreg: oh , you've just joined, you didnt see me posting this url
|moe|: thx
mcgreg: I'm putting my money already into WOW, thats enough ;)
mcgreg: thoiugh I am downloading the precompiled stuff from their homepage
|moe|: wonder it is not in the repos
mcgreg: http://secondlife.com/community/downloads.php <-- downloading from here
MostAwesomeDude: Yes! Laptop boots and talks to wireless. Halfway there.
mcgreg: congrats dude
|moe|: uni continues - got to listen, see you
mcgreg: have fun
|moe|: heh
MostAwesomeDude: Heh, I'm doing the ghetto gentoo install. Save /boot, /etc, /home, /usr/src, and just untar the rest from stage3.
mcgreg: hmm in general it works
MostAwesomeDude: mcgreg: In general?
MostAwesomeDude: I mean, it looks alright?
mcgreg: I just started it .. no problems occured, I a 3d world for now
mcgreg: I will make screenshots
MostAwesomeDude: 'k.
mcgreg: I have no idea how it should look, buit it doesnt look bad
MostAwesomeDude: Sounds like a definite silver, maybe gold?
mcgreg: silver at least yeah
mcgreg: http://mcgreg.dyndns.org/files/secondlife1_001.jpg
mcgreg: first shot
mcgreg: this is an ingame shot
mcgreg: http://mcgreg.dyndns.org/files/secondlife1_002.jpg
MostAwesomeDude: Will view later.
mcgreg: note, that you can only view then as long I am online/in this chat, else my computer is not running :)
MostAwesomeDude: ...
MostAwesomeDude: One sec.
|moe|: do you wear gloves or are the hands not displayed correctly?
mcgreg: hmm no, but the gfx are lowest possible quality
|moe|: or is this a general thing?
mcgreg: and it is already slow with that option :)
|moe|: wow - technology at it's best
mcgreg: I dont know if I have gloves since I didnt do anything with clothes at all
|moe|: i thought you chose that pretty outfit by yourself ;)
mcgreg: I will tets with better quality
MostAwesomeDude: ...cacaview is most unhelpful.
mcgreg: cacaview? what is that?
MostAwesomeDude: mcgreg: libcaca is a colorized ASCII library; it's very cool for watching videos on a text-only framebuffer at decent speed. cacaview is just a standalone image viewer...it doesn't look very good on non-moving images, though.
mcgreg: ahh haha
MostAwesomeDude: Think aalib, but with colors
mcgreg: you could just downlaod the imagines and watch them later? :)
MostAwesomeDude: mcgreg: That's exactly what I did. :3
mcgreg: it always takes a while until everyhting has finished download
mcgreg: it is a littrle liker google earth
MostAwesomeDude: mcgreg: Yeah, I remember them giving a talk on how the levels load.
airlied: |moe|: http://kojipkgs.fedoraproject.org/packages/kernel/2.6.25.7/65.fc9/
MostAwesomeDude: It's basically on-the-fly model loading.
airlied: can you try that kernel?
airlied: and see if it fixes the issue you were seeing
fpoibaf: airlied: can this fix: http://airlied.livejournal.com/59351.html be backported to mesa 7_0 branch?
airlied: fpoibaf: its actually alot of work.
|moe|: will download it and try in the break of my class
airlied: it might be possible to make a basic working patch.
fpoibaf: oh... the patch appeared to be very simple...
|moe|: airlied: thx in advance for your effort
airlied: fpoibaf: the problem was the srs480 code wasn't all in 7.0
mcgreg: MostAwesomeDude: i would say, second life works just fine, it's just very slow here. you could rate it even gold I think. I just dont have a comparison how it should look like
airlied: I forgot I backported it to the Fedora 7.0 modules
MostAwesomeDude: mcgreg: It's LAN-bound, believe it or not.
MostAwesomeDude: Are you on dialup or slow broadband?
mcgreg: actually my connection is very fast ... 16mbit download , my ping to my dialup is about 20ms or something similiar
mcgreg: no, I mean the gfx speed is very very slow
MostAwesomeDude: Hmm.
mcgreg: although I set it to high quality
MostAwesomeDude: I'll have to check this out. You're a RV530 IIRC?
mcgreg: no, rv515
MostAwesomeDude: Oh, same as me.
MostAwesomeDude: 'k, then. I'll look later.
mcgreg: http://mcgreg.dyndns.org/files/secondlife1_003.jpg
mcgreg: my gfx card is X1300pro .. well, it is crap
mcgreg: and I know this driver is heavily under development .. though the current speed , measured with WOW compared to windows is about 10%
mcgreg: I would guess
MostAwesomeDude: Dunno what to say.
MostAwesomeDude: We need a bot that just squawks, "Memory manager will solve everything, bawk! Make driver faster! Make FBOs work! Awk!"
mcgreg: you dont need to say nothing. you are doing a great work. just continue :)
MostAwesomeDude: mcgreg: Nah, I'm the lazy one.
MostAwesomeDude: airlied and glisse and nha and agd5f are doin' the heavy lifting. :3
mcgreg: so? nobody said you need to have it done in a week. a good driver needs it time
MostAwesomeDude: Indeed.
adamk: Guys, I expect all the bugs solved, with a 200% performance boost in exactly one week.
adamk: There, someone said it :-)
airlied: adamk: damn I'll swap you for a pony.
adamk: lol
airlied: for every pony I get, I'll add one memory manager :)
MostAwesomeDude: If I had the money, I'd totally send a pony to Australia.
MostAwesomeDude: Just for the hell of it.
airlied: MostAwesomeDude: I was hoping Mark Shuttleworth would send some :)
mcgreg: lol
adamk: I know someone who owns a few ponies... I don't think she's willing to part with any, though.
MostAwesomeDude: airlied: I tried it once, but all I got was a box of Ubuntu discs and a little note saying "Dear Colton, thanks for your support! ~M. Shuttleworth"
MostAwesomeDude: ...Dang, it must be getting late for my jokes to be getting so bad.
MostAwesomeDude: Two hours to sunrise.
mcgreg: last screenshot http://mcgreg.dyndns.org/files/secondlife1_004.jpg
MostAwesomeDude: Saved.
mcgreg: when I set the quality to low, the speed get noticibly faster
mcgreg: even usable :)
MostAwesomeDude: Hmm. Alright.
|moe|: mcgreg: what is the lang depending on? does an englishman see the same adds in englisch?
mcgreg: the language depends on the place. I chose a german town
|moe|: sounds like a plan ;)
|moe|: you can visit other towns, don't you?
mcgreg: probably , I've never used it before
|moe|: so do I, just for the case of being involved in an conversation about it ;)
mcgreg: ok, enough of second life
mcgreg: either this town wasnt very inhabited or there arent many SL-user anymore
|moe|: it'S friday morning after the quarterfinals of the europeanchamionship and yesterday was a big party for the germans (they won) so i giess they are all still in delirium or at work ;)
|moe|: or, like me, at university
mcgreg: unfortunately the damn germans won
mcgreg: I hope so much they would loose
|moe|: I am very happy about that fact ;)
|moe|: you shouldn't put money on that ;)
mcgreg: why? those over payed arrogant idiots
|moe|: the odds are 'gainst you
|moe|: will try the kernel now, it's break
mcgreg: I still count on italy, I hope they will kick ass teams asses ;)
mcgreg: ass=all
|moe|: have to boot into the new kernel, keep fingers crossed ;)
|moe|: airlied: screen remained black when it was ought to show me the bootup-process
|moe|: airlied: after booting into the .4-30 again it reported a kernel failure, sent it to kerneloops
|moe|: airlied: can i provide you some logs?
|moe|: going to have lunch now, see you
mcgreg: ok, I kased a friend about Second life you uses it too ... hey said: "I don't see any major graphical glitches. Though the textuers look a bit lowres - but that's probably because you don't have much patience"
|moe|: aloha
mcgreg: *you=who
|moe|: mcgreg: issue of online trust? or just a lack of memory? :)
mcgreg: well, I couldnt think 2GBram could be too few nowadays and 128MB VRAM is too few either
|moe|: this is why I switched from WinVista to Linux
mcgreg: Mem: 2063492k total, 1851880k used, 211612k free, 69080k buffers
mcgreg: Swap: 1951888k total, 676k used, 1951212k free, 848852k cached
mcgreg: this means, from my 2GB max 800mb is used , the other is free or some caches or buffers
mcgreg: wow xorg uses 15,1% of my mem?
mcgreg: isnt this a too much?
mcgreg: *+little
mcgreg: what does it need >300mb for?
xAFFE: maybe some flash objects within firefox? I expierienced that that increases the load and the memory usage drasticly
mcgreg: I just quit opera .. still 15%
mcgreg: I will restart X
mcgreg: hmm xserver git broke here, when I enter whatever in X, it freezes totally and crashes.
quicksilver: X server's memory usage includes mapped VRAM I think
IrCYop: I ahve a question, just how much specifications on the radeon 3870 was given to the opensource community? Did they leave some details out on a certain chip or something like that?
agd5f: IrCYop: display engine specs have been released. 3D engine stuff will be released soon
IrCYop: agd5f, Also, anyone know why crossfire is so much better than nvidias SLI? a friend of mine says "they probably just make one card on its own underperform to make crossfire look better and to pump more money from your wallet"
agd5f: IrCYop: better designed
IrCYop: Can you further explain?
MostAwesomeDude: IrCYop: I thought it had to do with how the GPUs talked to each other.
MostAwesomeDude: Also your friend is quite wrong, as ATI chipsets perform fine on their own. AFAIK there aren't any ATI boards that are only partially-enabled like nVidia cards sometimes are.
rx__: partially-enabled?
MostAwesomeDude: rx__: Lots of nVidia chipsets are underclocked or have pixel pipes flicked off in the video BIOS so they can be sold as lesser cards.
rx__: ati has done that in the past
MostAwesomeDude: rx__: Really? I didn't know about this. Do you know which cards?
rx__: search x800gto -> x800xl soft mod
MostAwesomeDude: Huh. It's just a switch in the BIOS?
rx__: nods
MostAwesomeDude: Learn something new every day, I guess.
rx__: i read their new focus is to do R&D for a mainstream part.. then scale up and down from there
rx__: whereas nvidia is high end part first.. then scale down
MostAwesomeDude: Well, it's understandable; I just don't think it's very cool to try and trick people like that.
rx__: afaik it's a common thing to do in HW industry
MostAwesomeDude: I mean, Intel and AMD have always followed a policy of using genuinely lesser-grade chips for lower-clock-speed CPUs.
rx__: oh bad pipe? disable it.. mark it as a lesser model
MostAwesomeDude: rx__: Right. That's the whole idea behind the AMD 3-core CPUs.
rx__: yea
MostAwesomeDude: There was a big problem with the manufacturing process, so core #3 on 4-cores was often bad, so they just flicked it off and let Marketing handle the rest.
MostAwesomeDude: Pretty ingenious, IMO.
rx__: better than binning it
rx__: *drool* 4850
MostAwesomeDude: It's stuff like "Oh, we'll just ship this 8-pixel-pipe with four pipes disabled for no reason" stuff that irritates me.
rx__: oh
rx__: ohh..
rx__: for that well..
otaylor: I don't really see any problem with that ... it's the same model as a software vendor selling different versions of software with more or less features
otaylor: It doesn't cost the software vendor any more to make a dvd with all the features, as compared to just some of the features
rx__: i think that's more down the road.. when their yields become too good
rx__: and thus have to disable still functioning pipes for the lesser model
MostAwesomeDude: Well, I mean, the only reason I can see for it is to try to saturate more of the market, but it could also backfire big-time if people were ever to learn en masse how to work VBIOS editors.
rx__: i think value conscious people know how to work vbios editors ;)
MostAwesomeDude: I dunno. I never see it in the news, except for that one Quadro incident, so it just seems to me that not many people care.
rx__: you should probably be pointing the figure at the board partners then
glisse: MostAwesomeDude: i think now they use fuse to disable some pipe
MostAwesomeDude: glisse: That would make sense.
otaylor: MostAwesomeDude: I think you just assume that most people arent' going to be determined enough to muck-around in a warranty-avoiding way, and if they are, well, then hey, you just got a happy customer
MostAwesomeDude: glisse: As long as you're around, could I ask you about kernel modesetting?
glisse: MostAwesomeDude: of course
MostAwesomeDude: So I know that the Intel code uses sort of a switch in the kernel. If the DDX detects that the switch is flipped, it just lets the kernel handle modesetting.
MostAwesomeDude: What kind of mechanism do we have, if any?
MostAwesomeDude: Or do we have to tell the DDX at compile-time?
glisse: MostAwesomeDude: i done a special ddx
glisse: xf86-video-kms
glisse: but Alan is doing somethings similar with no code for radeon yet
MostAwesomeDude: glisse: Is that general-purpose, or Radeon-only?
glisse: i think we should do one ddx for all modesetting
MostAwesomeDude: So stuff like the textured Xv and stuff, where would that go?
glisse: the only specialized part is exa
glisse: well xv too but i have great hope in the xv gallium stuff
airlied: I'll be adding kms to radeon :)
MostAwesomeDude: glisse: As do I. The gsoc guy is doing some sweet stuff with XvMC.
airlied: distros can't pick and choose the driver its too much hassle.
otaylor: glisse: I'm not sure I understand the common ddx thing... isn't there still going to be a bunch of card-specific acceleration code?
MostAwesomeDude: Okay, so it would be kms + radeon-specific EXA?
airlied: also it would be nice to have some back compat on the output names
glisse: agd5f: i am bit disapointed adding flush & wait until in exa doesn't seems to help that much
otaylor: glisse: Wouldn't it be better to just have a ddx+modesetting library/module?
otaylor: glisse: That coudl be shared betewen drivers
MostAwesomeDude: Kind of like that USE_EXA system in some of the current drivers?
glisse: well i am at a state where lockup take longer to happen so it's hard to really compare
airlied: my intention was to move drmmode_display.[ch] into server side
airlied: when its generic enough
glisse: airlied: could work too
airlied: I think having a generic dirver is fine for embedded people
airlied: but for distros it makes no sense.
glisse: i guess the idea was that all kernel modesetting will end up being the same for all kms driver
MostAwesomeDude: As for the kernel side, what would I need to do to e.g. add my card to it?
glisse: otaylor: the idea was to choose things like exa based on card id
airlied: glisse: the code should be the same, but doing impedance matching between randr-1.2 and kernel modesetting
airlied: isn't very easy to do generic
airlied: as different drivers provide different radnr-1.2 interfacs now
airlied: I also need a migration path and fallback paths in the driver.
airlied: so I don't need to rewrite lots of things like xorg conf files.
glisse: airlied: makes sense
glisse: airlied: still one things that need to be done is rewritting exa cmd submission there is flaw in the stream somewhere
otaylor: glisse: well, obviously it's possible to have one monolothic driver, but that's as much true with or without modesetting, really. I don't really see how modesetting changes the equation other than making the drivers smaller
glisse: otaylor: well i didn't take the road of putting common stuff into core xorg
glisse: so i started that way :)
glisse: but airlied plan is fine too, it was just based on the observation that many things in kms world become share when it comes to ms btw different drivers
otaylor: glisse: Hey, well, anyway that works sounds like a good way to start :-)
airlied: and in any case without a memory manager its all moot :)
airlied: and you need devicve specifc code to allocate the frontbuffer
glisse: z3ro_: can we run revenge to trap cmd stream which are not from one the included demo ?
glisse: ie from an outside application
glisse: like iba does
glisse: doing dump is still usefull :)
kdekorte: airlied, I just ran SecondLife with the Fedora 9 updates-testing packages and it works surprisingly well...
kdekorte: about the only problems are with the water and the sun bouncing off it
kdekorte: This is on an R500 card
airlied: kdekorte: I think some of those might be fixed upstream, I need to sync mesa again :)
kdekorte: I'm using pretty stock F9, except I'm running metacity with compositing enabled..
kdekorte: Anyway, congrats on the progress
osiris_: airlied: congratulations!
MostAwesomeDude: kdekorte: Updated the games matrix, lemme finish building ssh so I can upload it.
MostAwesomeDude: 'k, uploaded.
MostAwesomeDude: Hey, so, the r7xx series still has 2D, right?
glisse: MostAwesomeDude: iirc no
MostAwesomeDude: glisse: So how do we draw stuff on the RV770?
agd5f: MostAwesomeDude: neither r6xx nor r7xx have a 2d engine anymore'
glisse: MostAwesomeDude: through the holy 3d engine :)
MostAwesomeDude: agd5f: Ah, I thought the r6xx still had some kind of emulation.
MostAwesomeDude: Wait, so atombios is responsible for all that magic stuff?
agd5f: MostAwesomeDude: nope
agd5f: atombios is just init and modesetting
kdekorte: r600+ is all shadow buffer then?
agd5f: MostAwesomeDude: on r6xx the CP emulates 2D packet3's on the 3D engine
MostAwesomeDude: agd5f: And on the r7xx?
MostAwesomeDude: I'm trying to understand exactly how that demo article with the RV770 works...
agd5f: MostAwesomeDude: you have to use the 3D engine
RTFM_FTW: 2D is little more than an illusion on R6xx+
MostAwesomeDude: I must have missed the part where we added support for the 3D engine to xf86-video-ati.
otaylor: MostAwesomeDude: You should realize that we really don't draw anything signficant with the 2D engine on any radeon
agd5f: MostAwesomeDude: how do you think EXA composite is implemented :)
otaylor: MostAwesomeDude: (other than some bitblits)
otaylor: MostAwesomeDude: Everything interesting is either 3D engine or software
RTFM_FTW: yep
agd5f: on r6xx I'd like to get EXA going on the 3D engine. the CP emulation is just a crutch, and with 7xx coming out, makes sense to use 3d directly
MostAwesomeDude: Huh. I guess it's just not going through the ENTIRE pipeline?
agd5f: MostAwesomeDude: sure it is
MostAwesomeDude: agd5f: Don't you have to wait until the docs are released, or are you allowed to just go for it?
MostAwesomeDude: ...I guess I should re-read the code.
agd5f: MostAwesomeDude: you set up state in RADEONInit3DEngine()
otaylor: MostAwesomeDude: in terms of "entire people" ... basically yes, though the vertex portion isn't very interesting
agd5f: then it's just a FP program and rendering quads
MostAwesomeDude: Hmm.
otaylor: (how did I type "people" rather than "pipeline" ...)
MostAwesomeDude: So, really, the r7xx doesn't pose any real challenges as far as driver structure?
agd5f: well, it's harder to program the 3D engine, but other than that, no
MostAwesomeDude: Well, IIRC the r7xx is designed after the r6xx?
agd5f: sort of, it's more of an evolution
otaylor: MostAwesomeDude: There may be some scalability limits to the current code organization too ... right now it's all full of "if (this chipset) emit_this_bit_of_fp_code eles if (that_chipset)..."
agd5f: kind of like r3xx->r4xx->r5xx
MostAwesomeDude: otaylor: Well, I mean, there's no way around that in a unified setup.
MostAwesomeDude: All of my cross-platform code is covered with #ifdef WIN32/#ifdef __linux__/etc.
otaylor: MostAwesomeDude: Well, you have various options for refactoring
otaylor: MostAwesomeDude: E.g., you could duplicate the entire function per chip family rather than having ifdefs in it, you could have vtables, etc.
MostAwesomeDude: otaylor: Mm, I see.
MostAwesomeDude: takes furious notes
MostAwesomeDude: Could be a cool idea for when I write more Gallium.
otaylor: it's nothing very exotic ... it's just figuring out what sort of code structure gives you the most clarity with the least amount of code duplication. Certainly not a fundamental change, but I'm not sure that the current code would survive adding r6xx and r7xx conditionals, without a bit of refactoring
MostAwesomeDude: I dunno. I remember a discussion on radeonhd, where they were thinking of adding r6xx to the r300 DRI.
MostAwesomeDude: That seemed really silly to me at the time.
airlied: the thing is most of the flow is the same no matter what chip.
airlied: its just a matter of picking a decent line in the sand.
MostAwesomeDude: But we should only have one radeon pipe for Gallium, so it's not really that far-fetched.
airlied: for gallium it makes sense to have one winsys and multipl pies
airlied: pipes
MostAwesomeDude: airlied: This is true. Chips follow the OGL/D3D pipeline.
airlied: and r300/r500 + r600 pipe makes sens
airlied: as the r600 vp/fp shares nothing with the r300/r500
airlied: but the buffer managerment should be the same
glisse: airlied: well for gallium after playing a bit i think that the best solution is to do hw cmd translation in the very last stage ie just bfeore sending to the hw
MostAwesomeDude: airlied: I dunno. The nouveau guys are doing everything unified, but maybe their chips aren't as dissimilar?
airlied: MostAwesomeDude: they've only done nv30 and nv40 so far
airlied: MostAwesomeDude: which is pretty much r300/r500 type differenecs
airlied: the nv50/g80 stuff would be interesting to see
MostAwesomeDude: Wait, IIRC the winsys shouldn't depend on the HW, right?
otaylor: airlied: the r300 vs. r500 combinationis reasonably tenuous too for the fp, though I guess you at least have the vp/fp split there
MostAwesomeDude: Or am I getting terms mixed up?
otaylor: airlied: But if you figured out a good way to split out the r600 fragment programs while keeping buffer management the same, then I think considering doing the same for r300/r500 might make sense. (I'm talking only 2D here)
airlied: MostAwesomeDude: winsys has buffer managerment so it does.
airlied: otaylor: r600 is unifed shader
airlied: so vp/fp isn't really that different.
MostAwesomeDude: otaylor: The different FP requires different RS setup and ultimately different VP when we start working on GLSL.
MostAwesomeDude: WRT r5xx.
airlied: MostAwesomeDude: some of the GLSL stuff though is good for r4xx :)
otaylor: MostAwesomeDude: I recall the RS setup is completely split r300/r500 in the 2D driver already
MostAwesomeDude: otaylor: Not surprising.
MostAwesomeDude: airlied: It seems to me like we're going to have to just write a bunch of different functions for each piece of the pipeline on each chip, and then pick and choose per-chipset.
glisse: MostAwesomeDude: i don't think saw
glisse: the idea is that most high level information is the same
otaylor: MostAwesomeDude: of course, long term, just writing the DDX on top of gallium might be the way to go, and punt the whole question over there :-)
glisse: often only register layout have change a bit
MostAwesomeDude: Well, I mean, at some point we have to turn that high-level stuff into low-level stuff; where in Gallium is that supposed to happen?
glisse: MostAwesomeDude: this is why i am thinking that we should convert it the lastest possible
glisse: also we gonna need to modify lot of things depending on different part of the pipeline
MostAwesomeDude: glisse: So we have one pipe, which looks suspiciously like the intel pipe. Then we have a winsys driver that's responsible for all radeon chips, or multiple winsys drivers?
glisse: for instance if we modify pixel shader we might need to modify vertex shader
glisse: MostAwesomeDude: it could be different pipe sharing some same source files
glisse: and one winsys driver is far enough :)
MostAwesomeDude: glisse: Okay, so I have it backwards, then.
glisse: MostAwesomeDude: the idea is that we need to modify a lot of things depending on state change and it's easier to modify high level things that low level
glisse: s/that/than
damentz: hey guys btw
damentz: i'm not even using mesa/dri git
damentz: and r300 runs warsow really fast
damentz: i was playing at 1440x900
damentz: always over 60fps
damentz: but then mine has 256mb of video ram
glisse: agd5f: things are strange :) as long as i do not submit indices through ib2 it seems i can't lockup
agd5f: glisse: weird.
glisse: of course it's hard to tell maybe lockup will take lot more time to happen but really
glisse: i don't think it will lockup 3 glxgears moving on top of celestia is not somethings where my card last long
glisse: i will try to fill fifo after indices
glisse: that might help
MostAwesomeDude: Hehe, sorry. Internets problesm.
MostAwesomeDude: *problems, even.
MostAwesomeDude: Okay, so how do we decide which pipes to make?
MostAwesomeDude: I mean, do we keep the current scheme? r1xx/r2xx, r3xx/r4xx/r5xx, r6xx/r7xx?
glisse: MostAwesomeDude: i think so
glisse: i can't tell for r6xx/r7xx
MostAwesomeDude: glisse: So what do we do for rs480 or rs690?
MostAwesomeDude: ...Wait, stupid question.
glisse: MostAwesomeDude: basicly for each stage you look at what value/informations you need if you need same kind of informations accross different hw then this makes sense to share this informations
MostAwesomeDude: If we approach each pipe as a unified system that only diverges in a few spots, then rs480 and rs690 fit perfectly into the r3xx-r5xx pipe.
MostAwesomeDude: Hmm.
MostAwesomeDude: And then it's up to the winsys to handle each different piece of HW directly.
glisse: MostAwesomeDude: no, in gallium where you finish building a context you do that last pass which translate high level into the specific bit for the hw, note that when i am saying high level here and i thinking already to stuff that might look lowlevel to others :)
MostAwesomeDude: glisse: Oh. I see.
MostAwesomeDude: So at the end of the pipe, we're supposed to have something similar to the big thing of state that we have in DRI?
glisse: yup
glisse: basicly gallium will ask you to translate a particular state and will cache the result
MostAwesomeDude: glisse: So, then, we could have both r3xx and r5xx FP state, and just only emit one depending on current chipset?
glisse: then it bind a state with draw cmd
MostAwesomeDude: AAh.
MostAwesomeDude: Okay.
MostAwesomeDude: That's starting to make a lot of sense.
glisse: zzzZZZzzz time
glisse: cu
MostAwesomeDude: glisse: Bye.
rx__: MostAwesomeDude; did you have an issue with synaptics?
MostAwesomeDude: rx__: Yes. Even with cbrill's patches, it won't compile against master.
MostAwesomeDude: I'll try again in a few, once I'm finished (re)building X.
rx__: oh
rx__: damn was going to ask if you found a fix :)
MostAwesomeDude: rx__: I don't know anything about X input, and haven't really looked at it.
MostAwesomeDude: I've just been carrying around a USB mouse.
rx__: ah
rx__: learns to navigate with keyboard instead
spstarr: oh wow...something just seriously bumped the r300
spstarr: perhaps kwin fixed some composite issues.. or newer Xorg snapshot
spstarr: airlied: did you do something? ;-)
cokane: ?
cokane: is it working better for you now?
spstarr: cokane: acceleration is
cokane: ah
spstarr: i did tweak my config though a alittle
cokane: what was it not doing before?
spstarr: Option "MigrationHeuristic" "greedy"
cokane: I've been having trouble with locking + race conditions in the server/driver/drm/kernel
spstarr: Option "EnablePageFlip" "on"
spstarr: cokane: i still have locking/race conditions
spstarr: but it only happens if i futz around with kwin and composite enabling/disabling
cokane: ah
cokane: I hit them in EXA a lot
cokane: and since earlier this week, I can't even start my Xserver now
spstarr: page flipping seriously does some acceleration improvements
spstarr: i wonder why its off by default
MostAwesomeDude: spstarr: I thought it was because it was unstable.
spstarr: seems more stable with it on
spstarr: with this i can use composite now on the r3xx
cokane: hm
cokane: did it lock up before?
cokane: maybe that forces it to be more serial
spstarr: it locked before during use.. so far no
spstarr: but it locks up if i touch enabling/disabling composite
damentz: hey MostAwesomeDude, the changes in mesa's dri code for all those radeon cards
damentz: are some of the mshared?
damentz: like, will the r100 cards get an unexpected benefit?
MostAwesomeDude: damentz: Um, all cards now have official microcode thanks to AMD.
MostAwesomeDude: But in DRI?
MostAwesomeDude: Um, you'd have to check.
MostAwesomeDude: AFAIK no, not really.
damentz: darn
MostAwesomeDude: damentz: Is there something specific you're hoping for?
damentz: nah, just performance boosts
damentz: the radeon 7500 is still a fast card!
damentz: especially the mobility
damentz: it's better than intel's crap at least
damentz: to this day
damentz: and it was released in like what, 1998?
cokane: the intel chips are bottom-end
damentz: at some point in the year, they should be faster than the higher end 10 years ago
damentz: otherwise they're just abusing their monopoly
cokane: heh
cokane: i hear the latest GMA2 things are supposed to actually be decent
cokane: at least for a non-nvidia and non-amd gpu
MostAwesomeDude: Okay, since #xorg is unhelpful (as usual,) does anybody know why I'm getting problems building xserver?
MostAwesomeDude: Bunches of _GLXDRI* and __DRI__* errors.
cokane: any number of reasons
cokane: did you install dri2 ?
MostAwesomeDude: And it's all in glxswrast, if the helps.
cokane: from git ?
MostAwesomeDude: cokane: Yeah, I got dri2proto.
cokane: or 1.4.2
MostAwesomeDude: cokane: There's dri2proto 1.4.2!?
spstarr: no DRI2 for radeon yet (r3xx)
cokane: xorg-server from git?
damentz: hmm
MostAwesomeDude: Oh, xserver.
MostAwesomeDude: Yeah, it's from git.
damentz: how do i trick mesa into building
damentz: it keeps saying i don't have libdrm 2.3.1...
damentz: and i have drm from git
damentz: so it's like
damentz: uhh, right
cokane: MostAwesomeDude: you should try clearing out your git tree and resyncing
MostAwesomeDude: cokane: Ehh. I really didn't wanna do that.
MostAwesomeDude: I already cleared out and pulled the latest head.
cokane: have you been tracking xorg-server git and mesa git for awhile?
cokane: you may need to also clear stale headers from /usr/local/include
MostAwesomeDude: cokane: I'm installing directly to /usr
MostAwesomeDude: This is a brand-new install.
cokane: so no previous headers lingering...
cokane: well, what are some of the errors
cokane: ?
MostAwesomeDude: log of the errors: http://rafb.net/p/FBYIzn13.html
cokane: 404 not found
MostAwesomeDude: log of the errors: http://rafb.net/p/FBYlzn13.html
MostAwesomeDude: Sorry, mistyped.
cokane: did you install the latest driproto too?
cokane: it really looks like your proto is out of sync w/ the libs
MostAwesomeDude: Yeah, I konw.
spstarr: ouch
spstarr: kwin just took out X
cokane: it happens
spstarr: heh
spstarr: thats the first segfault from Xorg in a long time
rx__: airlied; congrats :)
spstarr: what im noticing is, the fan on laptop is not turning on with composite and r300 now
MostAwesomeDude: spstarr: That's good to hear.
spstarr: yes, indeed
spstarr: this would be the first time, the driver has done this
spstarr: MostAwesomeDude: it's telling me that more of the GL operations are being rendered accel/HW vs fallback sw
MostAwesomeDude: Hmm, nothing in my /usr/include defines __DRI_CORE
MostAwesomeDude: That's probably a sign that I misinstalled something.
dmb: MostAwesomeDude, what dist?
MostAwesomeDude: dmb: Gentoo.
MostAwesomeDude: dmb: You can help. Try "grep -R __DRI_CORE /usr/include" and see which file defines it.
dmb: MostAwesomeDude, nothing
MostAwesomeDude: dmb: Wonder if I've just been nicked by some kind of "too-new" thing in xserver.
MostAwesomeDude: dmb: Found it. It's in Mesa headers, but was removed recently, I guess.
dmb: dunno
dmb: oh
MostAwesomeDude: WTF.
MostAwesomeDude: So I noticed that all my missing defines were in Mesa.
MostAwesomeDude: And then all of a sudden it works.
MostAwesomeDude: I guess it forgot that I installed Mesa...?
MostAwesomeDude: Whoo, X installed.
MostAwesomeDude: So, should I try KDE4?