amarsh04: hi dileX
dileX: hi amarsh04
amarsh04: I'm not trying to build any new code at the moment, just have the Debian unstable "radeon" module for my Radeon 9200 SE (RV280) card
dileX: someone here problems with DPMS? So I am using glisse's drm-next-radeon kernel with Linus-tree on top. 'xset dpms force off' is not turning off my notebooks LCD.
dileX: I am trying with "git reset --hard e36ebaf49274ffa78f17b62bcae4c92c33b5b391" to see if comiit "drm: Hook up DPMS property handling in drm_crtc.c. Add drm_helper_connector_dpms.
dileX: ...is the trouble-maker.
MostAwesomeDude: dileX: If you have a known good commit, why not git bisect?
dileX: MostAwesomeDude: the last good kernel was d-n-r and Linux-2.6.30-rc8. the problem must be introduced with >= git1.
dileX: MostAwesomeDude: can you describe the process of git-bisecting?
MostAwesomeDude: dileX: "git help bisect"
MostAwesomeDude: You basically mark one commit as bad, and then an earlier commit as good.
MostAwesomeDude: Then, git will pick a commit in the middle, and you build and test that commit, and mark it as good or bad.
MostAwesomeDude: And a few tests later, you'll know which commit is the problem./
dileX: MostAwesomeDude: OK, git-bisect is helping to find the bad commit by "protocolling" which commit is good/bad. nevertheless, I have to compile till I find the culprit.
dileX: speculates a certain commit as culprit (hope to reduce the number of builds)
MostAwesomeDude: dileX: In all seriousness, bisection is *really* fast.
dileX: MostAwesomeDude: with git-bisect I have not to do a git-hard-reset?
MostAwesomeDude: dileX: It does it for you.
dileX: OK, thats an advantage and of course the "history" ("protocol") which commit is/was good or bad.
MostAwesomeDude: It's pretty much just the automation of a popular kernel debugging technique.
dileX: MostAwesomeDude: hehe, I used good old pencil and sheet of paper for my history :-)
dileX: the git-manual says I can even give a range of commits, cool
maleadt: are there any reports of -ati suddenly blanking the screen? It's the second time my screen just "goes down" for a couple of seconds. Xorg.log reports a crtc-blanking (http://pastebin.com/m47607cb8). rv770@ ddx git master, drm git master and mesa r6xx-rewrite
amarsh04: dileX - I used gid-bisect on a PII-266 with the Linux kernel to find the commit that caused the EATA scsi driver to fail (took quite a few days). Once I posted the problem to linux-scsi, I had a patch posted within 11 hours
dileX: amarsh04: git-bisecting is only a tool. if you have a suspicious commit or can say when you discovered the problem than its good, otherwise...
amarsh04: I know, dileX... if multiple factors contribute to the problem, git-bisect might only point you to one of the factors
amarsh04: I went from where kernel 2.6.22 was ok, and the then current 2.6.27 kernel was bad - lots of commits in between
airlied: MostAwesomeDude: btw what you done with r300 FS?
airlied: in gallium
MostAwesomeDude: airlied: Nothing. :3
dileX: amarsh04: thats probably no.2 of the drm-fixes doing bad things, last one was reported on LKML and I didnt read.
MostAwesomeDude: I've been avoiding it. :C
airlied: not sure how fixes can break radeon kms since it isn't in master
airlied: any ideas how to hook it in?
MostAwesomeDude: ^^ @ /me?
airlied: MostAwesomeDude: of course :)
airlied: MostAwesomeDude: like would it be much different to how classic mesa works?
MostAwesomeDude: Well, I've got the split already set up, and emission/state tracking/bind all works.
MostAwesomeDude: Mostly, I've just got to write the code for actually compiling the shaders.
MostAwesomeDude: Which is going to be unfun because r300 fs sucks.
airlied: just wondering how much code from classic we could steal?
airlied: I know you like understanding code but I don't really care :)
MostAwesomeDude: Honestly, the only problem I have with nha's code is that I don't think I could maintain it.
MostAwesomeDude: s/maintain/add FC and other GLSL goodies/
MostAwesomeDude: Additionally, the r300 vs code *needs* to be rewritten. It's atrocious.
MostAwesomeDude: It's only "my" code because I've written most of it at this point. If other people wanna add code, go for it.
airlied: I was mainly thinking about rs690 playing around
airlied: so VS no matter
airlied: I was wondering if I could gain a VS speedup by using llvm+gallium
airlied: but I'd need FS to test of course
MostAwesomeDude: Yeah, r300 fs is a pain, and I've done r500 fs before, so naturally that's the one I did first.
MostAwesomeDude: is lazy
airlied: I'm just raelly couching surfing it all at the moment,
MostAwesomeDude: I approve heavily of couch surfing.
airlied: trying to think about texture tiling was proving too mcuh effort
airlied: esp for a day off
MostAwesomeDude: Aw, now I remembered that I need to make mipmaps work.
MostAwesomeDude: And FBOs.
MostAwesomeDude: And NPOT.
airlied: so all the useful stuff :)
MostAwesomeDude: Pretty much.
MostAwesomeDude: I'm still kind of amazed that trivial/tri works, much less glxgears.
glisse: airlied: yup will correct the author things, will do ttm patchm i think Thomas is busy with rl
glisse: airlied: i should still sign-of the pathc right ?
airlied: glisse: yes you shuold
amarsh04: finally enabled exa on rv280
amarsh04: 377 fps on glxgears
dileX: hmm, OK 2.6.30-rc8-00005-gc9fb15f is not the culprit
amarsh04: this machine run extremetuxracer at 0.3 fps (-:
amarsh04: hmm... exa seems to be making nspluginviewer on konqueror crash /-:
glisse: airlied: ok so my branch drm-next-merge should have all patches passing checkpatch.pl (beside false negative and line over 80)
nanonyme: glisse: How's the code looking considering the merge?
glisse: fighting with kconfig
airlied: glisse: did you apply my kconfig patches?
airlied: glisse: that make TTM not an option
glisse: airlied: i think i did
glisse: oh it seems i overwritte it in the process of making patch
airlied: I'm doing a test build on powerpc some issues :)
airlied: dinner time now
glisse: i am making radeon kms a staging driver but somehow my if logic is wrong in kconfig
glisse: it seems kconfig if things is broken
osiris_: airlied: I think you've forgot to push my regression fix
glisse: airlied: ok updated patch so kms only built as a staging option
glisse: osiris_: so you see corruption with kms on rs690 too ?
glisse: you work with kms off right ?
osiris_: glisse: yes, I see corruption only when kms is enabled
glisse: osiris_: does lastest radeon-rewrite build for you ?
glisse: autotools gone crazy
osiris_: glisse: yes, it does
glisse: osiris_: does it works with radeon-rewrite & kms ?
osiris_: glisse: yes, after applying my regression fix
glisse: osiris_: which one ? shader ?
osiris_: glisse: no, the one in More radeon-rewrite patches thread
glisse: it segfault with clean built for me
osiris_: glisse: what app?
glisse: all gl app
osiris_: do you have bt?
osiris_: glisse: maybe it's 32bit vs 64 bit issue
nanonyme: doesn't understand how 32bit vs 64bit should be an issue unless someone's silly and uses int somewhere
nanonyme: (Since then if one part is compiled as 64bit and another 32bit, int has two different sizes \o/)
airlied: nanonyme: its not ints, its longs
airlied: nanonyme: int is the same
nanonyme: airlied: Err, no? Isn't int a 64bit variable on a 64bit computer?
nanonyme: Have to explicitly define a 32bit variable to use them.
airlied: osiris_: I suck
airlied: nanonyme: you fail
airlied: osiris_: pushed it now
MrCooper: nanonyme: to be precise it depends on the ABI, but I think all Linux ABIs define int as 32 bit
glisse: don't understand why it segfault for me on kns
MrCooper: glisse: clearly you haven't sacrificed enough goats today ;)
nanonyme: airlied: You're right. sizeof(int) == 4 even on -m64. :)
glisse: is their any git tools to quickly switch btw revisions of a file ?
nanonyme: (Hmm, or is that even reliable)
osiris_: glisse: git checkout
nanonyme: Right, is there *any* thing about the arches that could prove a problem then? o.O
airlied: nanonyme: windows is 32-bit long also i think
nanonyme: airlied: Hmm, I meant regarding x86 and amd64.
nanonyme: I already found out you were right after a short googling and experimenting.
airlied: nanonyme: casting pointers to ints
airlied: or passing long/pointers in ioctls where you have 32-bit userspace on 64-bit kernel
nanonyme: I think I've bumped into someone doing that myself too.
nanonyme: As in, casting.
osiris_: airlied: thanks
nanonyme: airlied: The second one sounds like pain. How do you work it around, some address remapping?
airlied: nanonyme: special ioctl compat handlers
jcristau: they're preserved when you push/pull. not when you use git am.
jcristau: (different committer, different commit date)
osiris_: jcristau: good to know :) I'm still learning the git
nanonyme: Isn't mostly everyone still learning the git? ;) It has damn many features. :)
airlied: osiris_: not after I pushed it :)
hgb: Hi. I have a F11 box running stock Xorg and radeon driver, and I have a question about duo-screen.
hgb: The card has two DVI connectors, and I want two monitors, each with its own screen.
hgb: :0.0 and :0.1 typically.
hgb: Currently, the two monitors have the same image on them.
hgb: I have an empty xorg.conf (or, rather, no xorg.conf(
hgb: 1) Is this possible? 2) Is there lots of work to fix?
nanonyme: So what you want isn't one big display area that extends ranging both monitors but two completely separate ones?
hgb: I've always run like this (it was the only option back in the days), and I find it very convenient.
hgb: For example, fvwm2 isn't nearly as good at placing windows with xinerama-ish setups.
hgb: Can one set up an almost-empty xorg.conf with just the ServerLayout section with two screens in it?
airlied: hgb: you neeed screen sections, driver sections
airlied: I sosrta tested it worked once during F11 dev
hgb: airlied: Okay. Those sections can be semi-empty, or?
airlied: you need to nearly a full config
airlied: for outputs
nanonyme: thinks it might have been the worst timing ever for him to install Fedora :p
hgb: starts out with an empty xorg.conf
hgb: airlied: driver section == 'Section "Device"'?
nanonyme: Sounds like it.
hgb: Hmm. It says no driver specified for Screen, but there is a "Device" entry there..
glisse: osiris_: so with kms you get revalidation failure right ?
airlied: hgb: you need two device sections with a Screen and BusID in it
airlied: two Screen setions referencing the device sections
airlied: and a serverlayout referencing the two screens
airlied: zzzz &
hgb: locates BusID
hgb: airlied: Cheers.
p4ddY`: hm, shouldn't kde4's desktop effects work using the xrender extension on a r7xx gpu?
lucxxx: maybe with mesa/r6xx-rewrite branch
lucxxx: see this tutorial here http://www.phoronix.com/forums/showthread.php?t=17603
nanonyme: lucxxx: He's talking of XRender extension, not OpenGL.
spstarr: p4ddY`: I dont know if there is XRender accel support on the r6/r7xx i dont think so yet
nielsslot: p4ddY`: some of them should.. they work fine here on my R600
p4ddY`: hm, doesn't work for me
nanonyme: p4ddY`: I'd rather use the term "might" than "should". KDE EXA compositing afaik didn't use to work that well with radeon.
p4ddY`: can't enable them.. i'm just not sure whether it is an archlinux issue (maybe they didn't compile that option)
nielsslot: i'm running kubuntu jaunty.. i do remember having to check the 'disable functionality checks' thingy..
[Enrico]: p4ddY`: so you are still running kernel .29?
p4ddY`: [Enrico] exactly
nanonyme: spstarr: Oh, that didn't come with EXA?
[Enrico]: p4ddY`: you need .30 i think
[Enrico]: p4ddY`: or you need to compile the git code for kernel drm modules
p4ddY`: hm.. well actually exa acceleration works just fine.. even xvideo extension works flawlessly on 1080p content
agd5f: p4ddY`: xrender should work. what's the problem?
nanonyme: You should be able to, yes.
p4ddY`: well, when i try to enable it, systemsettings says: "Failed to activate desktop effects ... blabla"
nanonyme: (I think. Or at least it should let you use XRender even if it doesn't give a choice. I haven't used it much)
agd5f: p4ddY`: any reason why it failed?
p4ddY`: checking "Disable functionality checks" doesn't work either
nanonyme: agd5f: Know of any simple utility to check if XRender starts up at all for him? :)
nanonyme: (That is, might help in locating the problem)
MostAwesomeDude: p4ddY`, nanonyme : $ grep EXA /var/log/Xorg.0.log
nanonyme: MostAwesomeDude: Oh, so EXA should have it *always*?
p4ddY`: (**) RADEON(0): Option "AccelMethod" "EXA"
p4ddY`: (==) RADEON(0): Will attempt to use R6xx/R7xx EXA support if DRI is enabled.
p4ddY`: (II) RADEON(0): Setting EXA maxPitchBytes
p4ddY`: (II) EXA(0): Offscreen pixmap area of 124944384 bytes
p4ddY`: (II) EXA(0): Driver registered support for the following operations:
MostAwesomeDude: Seems like a success to me.
MostAwesomeDude: So not sure why Xr effects would fail.
agd5f: nanonyme: it EXA and Xv are available, the so is xrender
agd5f: it's part of EXA
nanonyme: Actually seems Xorg.0.log should say that too.
nanonyme: Or is it that "Composite (RENDER acceleration)"?
agd5f: nanonyme: bingo
p4ddY`: so what?
p4ddY`: [patrick@bowmhouz] ~ $ grep Composite /var/log/Xorg.0.log
p4ddY`: (**) Extension "Composite" is enabled
p4ddY`: (II) Composite (RENDER acceleration)
nanonyme: So yeah, you have it. ;)
FallenWizard: what the hell? Didnt now that the desktop effects work O_o
nanonyme: FallenWizard: On EXA, yes. Not otherwise. Means eg Compiz does *not* work.
nanonyme: (And apparently even problems with XRender extension)
FallenWizard: this works for me
p4ddY`: what? o_O
FallenWizard: It's a little bit slow though
FallenWizard: but it's acceptable
nanonyme: Right. Do a comparison on X driver versions and DRM module versions? :)
valgaav: Hi :)
valgaav: I tried the ubuntu Xorg edgers cd that has newest kms /gem / mesa 7.6 code and as I know it's experimental I was wondering if any reports on how it works on rs690 would be useful for devs
valgaav: bug 20273 seems to be back for me , though agd5f was so nice to fix it earlier
valgaav: btw bugs.freedesktop seems to be ofline
valgaav: bug 20273 was basicly artifacts and flickering when compositing or exa was enabled
agd5f: valgaav: the kms ddx hasn't had master merged into it in a while
agd5f: still missing a lot of stuff from master
valgaav: ah ok :)
valgaav: also the performance in one game I tried was unplayable
valgaav: while it was finally displaying ok like it should with not inverted colors it had terrible 3-5 sec lags
valgaav: I know the code is experimental :)
valgaav: Anyway it seems very promising nevertheless
valgaav: suspend finally worked out of the box with no hacks, yet I dunno how much releated to radeon/kms that is ... nevertheless that was a wow for me :P
[Enrico]: can i ask what's the status of r6xx 3d and a prediction on when it will be released? sorry if this is a boring 1 milion asked question :D
MostAwesomeDude: Asking is fine.
MostAwesomeDude: It's released.
MostAwesomeDude: Just not usable.
MostAwesomeDude: It's currently highly experimental, not really doing anything.
[Enrico]: MostAwesomeDude: thanks :D
[Enrico]: MostAwesomeDude: i had an idea of trying the mesa branch for it
MostAwesomeDude: Not really worth it yet.
[Enrico]: MostAwesomeDude: i guess, i will wait :D
raevol: MostAwesomeDude: what's the relation between 3d and gallium? are we waiting on them for something? (or something?)
MostAwesomeDude: raevol: r6xx Gallium is waiting on kernel parts.
[Enrico]: gallium :Q______
[Enrico]: and llvm too
[Enrico]: MostAwesomeDude: :Q____ is a dribbling face :D
Zajec: probably better question would be about estimate time of working glxgears :)
Zajec: (mesa 3D for now)
[Enrico]: MostAwesomeDude: like homer (simpson) when he thinks donuts :D
[Enrico]: FallenWizard: exact :D
[Enrico]: MostAwesomeDude: i do the same when i hear something about gallium :D
spstarr: FallenWizard: you're making a OpenGL 3d doughnut ? :)
FallenWizard: I can't code
spstarr: I think GLUT makes it easy to create a 3D rendered (simple shading) doughnut ;)
MostAwesomeDude: There's a donut test.
spstarr: MostAwesomeDude: not surprised ;)
beekeeper: is this the right place to ask about opengl performance on the r300 mesa driver?
beekeeper: i'm writing a game that uses vertex buffer objects, float vertices and normals interleaved and 2-byte indices using glDrawElements
beekeeper: i get absolutely no performance difference between using plain vertex arrays and using VBOs on mesa 7.4 r300
beekeeper: now the code works for sure on nvidia blob and ati fglrx, and win32 also. big increase in fps
MostAwesomeDude: beekeeper: This is the right place.
beekeeper: ah. you're the r300 gallium dude, right?
beekeeper: i'm looking forward to when that stuff is ripe for using :)
MostAwesomeDude: So am I. :3
beekeeper: how does it fit with the radeon-rewrite stuff?
MostAwesomeDude: Completely orthogonal.
MostAwesomeDude: So, right now, Mesa internally converts all elts to shorts, and all vert attribs to floats.
MostAwesomeDude: This is ridiculously painful.
MostAwesomeDude: Both nvidia and fglrx are a fair amount smarter.
MostAwesomeDude: Elements. Indices of vertex arrayx.
beekeeper: i'm already using shorts for indices and floats for vertices
beekeeper: am i right in suspecting that the r300 driver doesn't do real VBOs? that the vertices are not kept on GPU memory?
MostAwesomeDude: You're on the right track.
MostAwesomeDude: VBOs aren't exactly persisted in VRAM/GTT.
MostAwesomeDude: In classic r300, VBOs are re-uploaded constantly IIRC.
MostAwesomeDude: In an ideal world (radeon-rewrite or gallium) we would upload VBOs once, and then use them a shitload.
MostAwesomeDude: And I'm nearly certain that that doesn't happen in the pre-MM classic setup.
Zajec: beekeeper: it's little late :)
Zajec: oh, MostAwesomeDude answered... i didn't scroll window :)
Zajec: yeah, just wanted to say word about radeon-rewrite
beekeeper: radeon-rewrite fixed a terrible deadlock problem with my M52
MostAwesomeDude: That's good.
osiris__: MostAwesomeDude: as of yesterday r300 (radeon-rewrite branch) doesn't convert all attributes to floats and all indices to ints
osiris__: now we send the data directly to GPU without conversion
osiris__: but you're right about VBOs
MostAwesomeDude: osiris__: Good work. Is that exposed for all Mesa, or just r300?
osiris__: MostAwesomeDude: it's up to driver - driver need to implement vbo draw interface, otherwise vertex data go through tnl module which converts all to floats and ints
osiris__: MostAwesomeDude: currently only i965 and r300 does it
MostAwesomeDude: osiris__: Any idea how we could fix that for non-HWTCL chips?
osiris__: MostAwesomeDude: one would have to completely rewrite the tnl module, so that fallback functions could work on all format
osiris__: MostAwesomeDude: so it probably won't happen
osiris__: MostAwesomeDude: how does gallium deal with it?
MostAwesomeDude: osiris__: Draw. It uses floats internally and expects the driver to request formats.
MostAwesomeDude: But the driver doesn't have any information about the verts.
MostAwesomeDude: I'm really not sure how to handle it properly; we still use Draw to collate verts even if we're not doing vert shaders. (Doing it the other way is very unfun-looking.)
osiris__: MostAwesomeDude: what the draw module is for?
MostAwesomeDude: osiris__: TCL, mostly.
MostAwesomeDude: We're using it for the entire render stage because that was the easy way.
MostAwesomeDude: And it also avoids a lot of problems WRT vert formats.
osiris__: MostAwesomeDude: hmm, that sounds like the tnl module from classic mesa
MostAwesomeDude: Kind of, yeah.
osiris__: MostAwesomeDude: you should probably skip draw module completely if you're not going to fallback at any stage
MostAwesomeDude: osiris__: But I'm gonna fallback with the vert shader.
osiris__: MostAwesomeDude: yeah, but you should check before every render operation if fallback is needed, if not skip draw
osiris__: MostAwesomeDude: that's at least how r300 works now
beekeeper: well, bedtime. thanks for the answers & the coding
osiris__: MostAwesomeDude: I see draw_array, draw_elements and draw_range_elements in pipe_context struct. that's probably what you have to implement
MostAwesomeDude: osiris__: Already implemented.
MostAwesomeDude: I just have to duplicate all the render code.
MostAwesomeDude: Additionally, as I was saying, if I do that, then all the non-TCL chips get screwed.
MostAwesomeDude: I'd rather have something that works *with* Draw.'
osiris__: MostAwesomeDude: can't you switch between draw and no draw in runtime?
MostAwesomeDude: osiris__: Yes, but no Draw -> no TCL.
osiris__: MostAwesomeDude: yeah, but you could run draw module only if you it's needed (draw vs no draw switch would happen on per render operation, not during driver initialization)
MostAwesomeDude: osiris__: Yes, but non-TCL chips still get screwed.
osiris__: I think I'm missing something here
MostAwesomeDude: Because non-TCL chips will still have to use Draw, so they'll still have to have everything converted to floats.
osiris__: yeah, and for nonTCL chips draw module will always be enabled
MostAwesomeDude: So wouldn't it make more sense to just fix Draw instead?
osiris__: and for TCL chips you would only enable it when you have to fallback
osiris__: fix Draw = implement all the fallback functions to handle all data types?
osiris__: it would be a piece of cake with C++ templates
MostAwesomeDude: Yeah, I know, yet another reason to make Gallium a C++ library.
MostAwesomeDude: (Not that there's anything wrong with that.)
MostAwesomeDude: I'm gonna take this to #dri-devel.
TCW: any possible correlation between radeon foss driver and a going-crazy gnome-panel / metacity?
TCW: going-crazy = leaky, eats rum if it is nothing
moeSizlak: so what kernel is gonna be the one released tomorrow? -168 ??
FallenWizard: 2.6.30 will be released tomorrow?
TCW: EOF was my quit-message?
raevol: (04:42:04 PM) TCW left the room (quit: Remote closed the connection).
TCW: raevol, thx
moeSizlak: no i mean what f11 kernel will be in the official f11 release?
moeSizlak: cus 167 and 168 are quite buggy for me
airlied: glisse: where did the DRM_KMS_RADEON Kconfig go in the latest patches?
TCW: damn xfwm4 --replace (compiz was running) killed the whole X session... great, Anyone a slight idea what may cause this? Ati RV530 [Radeon X1600], >> ii xserver-xorg-video-radeon 1:6.12.2-2 <<
TCW: same with metacity --replace in a gnome session btw.
airlied: TCW: it might say in the /var/log/Xorg.0.log.old
obscure1: you guys know why i might be seeing this?:
obscure1: (EE) RADEON(0): [pci] Out of memory (-12)
obscure1: (EE) RADEON(0): [pci] PCI failed to initialize. Disabling the DRI.
TCW: http://paste.debian.net/38446/ <- airlied, it does not imho, but if you can make anything out of it...
TCW: obscure1, laptop / onboard ati chip?
airlied: nice the mesa driver segfaulted and crashed
airlied: not sure if we ever fixed that
obscure1: you got it
obscure1: er no
obscure1: this is my desktop, descrete ati card
TCW: airlied, huh?
airlied: TCW: its a bug in mesa
obscure1: (--) PCI:*(0@1:0:0) ATI Technologies Inc RV710 [Radeon HD 4350] rev 0, Mem @ 0xd
obscure1: 0000000/268435456, 0xfdce0000/65536, I/O @ 0x0000de00/256, BIOS @ 0x????????/655
airlied: I'm not sure what version you are running t
TCW: airlied, so you are at least very certain you know the issue?
TCW: airlied, ii libgl1-mesa-dri 7.4.1-1
TCW: same version for libgl1-mesa-glx, libglu1-mesa, mesa-utils, ...
airlied: TCW: well I've seen someone giving out about it before
TCW: airlied, maybe... yesterday? ;) then it was me :)
osiris__: airlied: there are at least two more bugs in r300 (radeonr-rewrite branch) that crash the X (one with KMS, one without KMS)
osiris__: airlied: and also few bugs that crashes only the app
TCW: airlied, any idea what I should do now? Raise a bugreport againts mesa?
airlied: TCW: good chance we fixed it in master already
airlied: osiris__: got bug nums or ways to trigger them?
TCW: airlied, hum... :)
osiris__: airlied: I got reproduce steps. first bug: run glean/makeCurrent tests on non-KMS (crashes X)
osiris__: airlied: second bug: run mesa/progs/tests/mipmap_limits and try changing some params
TCW: airlied, any feeling about the time / version when this bug was introduced?
cheetopet: getting compile errors from drm-next-merge - http://pastebin.ca/1452605
TCW: airlied, or maybe a bug-# / url for details?
cheetopet: from a clean tree, relevant (hopefully) part of .config - http://pastebin.ca/1452609
airlied: TCW: not really, its more of a try and reproduce with mesa master
airlied: if it stops happening we fixed it
TCW: airlied, no idea what mesa master is... something like the git or cvs branch?
TCW: airlied, will it be released and packaged some day in the near future?
airlied: no idea, as I said I'm not sure narrowed down what actually fixed that.
airlied: glisse: my AGP boxes appears to be happy enough on your kernel patches + DDX + radeon-rewrite
airlied: at least it runs a desktop + gears
airlied: intel agp 865 + rv350
airlied: "Unpin not necessary for f6615c00 !" on X shutdown
Kaapa: where can I find a sample xorg.conf to use with radeon?
Kaapa: my system is all screwed up when it comes to video
Kaapa: anyone here? Can anyone using radeon tell me the ouput of ldd glxgears?
chainsawbike: Kaapa, doing it
Kaapa: if you can, I'd appreciate xorg.conf too
Kaapa: from what I'm googling, flgrx is screwing all my system
chainsawbike: it does that
Kaapa: but it was a manual install, so I don know if it overwrote some important thing
MostAwesomeDude: Kaapa: Your libGL is probably hosed.
Kaapa: MostAwesomeDude: I've reinstalled mesa too :S
Kaapa: chainsawbike: that's it? :p
Kaapa: heh, I must have a lot of crap here
chainsawbike: my xorg.conf has a lot of extra crap in it...
Kaapa: ah, k
chainsawbike: dual screens and left overs from varous problems
Kaapa: ah, I have glxgears again
Kaapa: now - what are the changes of my system to resume frmo hibernation? :S
Kaapa: ok, if it doesn't wake up, I'll go to sleep
Kaapa: chainsawbike: MostAwesomeDude: thanks!
chainsawbike: np :)
MostAwesomeDude: Does anybody remember offhand how many constants r300 FS can do?
MostAwesomeDude: r300_context.h seems to indicate the rather low number of 32.
MostAwesomeDude: Oh, nevermind, looks like 32 is the magic number.
MostAwesomeDude: Damn, so small.
bridgman: yep, 3xx register spec seems to confirm 32
MostAwesomeDude: I'm thinking of splitting the constant buffers into two parts; consts and imms.
MostAwesomeDude: I'm trying to weigh how big I should make each segment.
MostAwesomeDude: VS has 512 const slots; r500 FS has 256. Stupid r300 having bad shaders. :C
bridgman: 512 or 256 for VS ? skimming through 5xx doc looks like VS has 256
MostAwesomeDude: pp63-64 indicate that both of them have 512 slots.
MostAwesomeDude: From CONST_OFFSET to UCP_OFFSET appears to be 512 in each (r300: 512-1024, r500: 1024-1536)
bridgman: agreed there's 512 slots of address space, but there may not be memory under all the addresses
bridgman: see top of p69
bridgman: this is worse than bible study
MostAwesomeDude: I dunno, I was raised Catholic, this is no biggie. :3
bridgman: then don't give up on law too quickly ;)
bridgman: it's not much different from high tech but you eat in better restaurants
bridgman: and have hotter secretaries
MostAwesomeDude: The 128-vector limit is for the total temporary memory; that's the magic number for temps, vert size, and vert out.
MostAwesomeDude: Yeah, one of the FCC lawyers spoke at my uni a few weeks ago. Very cool dude.
bridgman: also see top of p68
bridgman: also top of p101\
MostAwesomeDude: Okay, so I'll go with 256 for now.
bridgman: also top of p120
bridgman: oops, sorry ;)
ssieb: airlied: any more progress on RS690 or have you been busy with other stuff?
MostAwesomeDude: Yeah, writing out consts isn't a problem. I'm just rearranging the way that the constants are handled, so we don't have to recompile shaders every time they change.
airlied: ssieb: I've probably forgotten what I was meant to be doing
bridgman: MostAwesomeDude; nice, that has to help performance
MostAwesomeDude: bridgman: I certainly hope so.
MostAwesomeDude: Right now only 7FPS with TCL glxgears.
MostAwesomeDude: Which is *worse* than SW TCL.
ssieb: airlied: it's just generally quite broken... I can't even use KMS because of the phantom HDMI output.
ssieb: and once using KMS, there are other major issues
airlied: ssieb: well at the moment we are preparing it for upstream
ssieb: preparing what?
airlied: I'm hoping the new kernel tree fixes some of the issues
airlied: the radeon KMS code
bridgman: MostAwesomeDude; I think that's what we were getting out of 6xx/7xx classic mesa, so "chin up"
ssieb: airlied: is there something newer than what's currently in koji?
TCW: suggestion what kernel / xorg version to use for rv530 chips?
airlied: ssieb: its all in a kernel git tree.
airlied: ssieb: I've done no packages for fedora until we get it all cleaned for upstream
ssieb: ok, I'll keep watching...
MostAwesomeDude: bridgman: Yessir.
bridgman: I think I need sleep... I was just thinking how lucky you were to get three extra hours of coding time every night...
bridgman: definitely time for zzz
MostAwesomeDude: Oh, my coding time comes directly out of my sleep.
bridgman: ok, I wish you rapid coding then
embraceunity: wow, glxgears just experienced a 500% increase in speed
embraceunity: whatever you guys did, good job
dmb: embraceunity, kms?
embraceunity: dmb: i did try to install kms recently, but it didn't work.... im on the old kernel... but i guess the cs3 version of the radeon driver is better or something
embraceunity: though i think i remember trying glxgears yesterday with this driver and seeing no improvement
embraceunity: i will post the kernel panic message now if anyone's interested
embraceunity: it said something about radeondrmfb failing
embraceunity: im using the radeon-kms repo for karmic kubuntu
DanaG: oh yeah, where is said repo, anyway?
DanaG: ... and can it at least do 2D on r600?
DanaG: ah, found it.
DanaG: benchmark:Run benchmark (int)
DanaG: hmm, what does that module parameter actually do? "run benchmark" is not specific.