peterz: airlied: xset dpms force off -- doesn't seem to stick, it does power off the things but then they come back on (black screen though, but powered on backlights)
airlied: come back on straight away? or after a while, it could be gnome or other things.
sannes: Just noticed some strange corruption or effects when I run glxgears with the newest git (don't know when it started doing this however, since I don't run much gl applications) .. the effect is that new windows get a yellow color when running an glxgears, screenshot here: http://www.sannes.org/misc/glx-corruption.png, especially if I move glxgears around ..
sannes: is it known?
MrCooper: sannes: first time I see it... could be scissor registers getting messed up (in which case it could be related to the textured Xv tearing avoidance changes) or something like that
sannes: In that case I'll bisect it when I get back home tonight (if noones beats me to it) ..
legume: sannes problem - looks a bit like mine https://bugs.freedesktop.org/show_bug.cgi?id=18328
legume: I managed to bisect radeon back to a version that worked in the past and it is still borked. So I think it's X (or my inability to build properly)
legume: sannes1: https://bugs.freedesktop.org/show_bug.cgi?id=18328 Are you using recent Xorg git? I bisected and it seems radeon isn't the problem.
legume: sannes1: Could be a different issue - If you maximise a terminal, fill it with text then run gears does the text below the gears window get cleared when it outputts the framerate?
legume: airlied: Are you interested in bug report for non working tv out on r500 or waiting for AMD to give more info?
sannes1: legume: could be, I'll check it later, it is also often an animated effect as in all the yellow flashing on and off ..
sannes1: legume: off the top of my head I think I'm running 1.5.3 and mesa 7.2
legume: sannes: OK I don't see flashing but it still seems similar - I only have xterm and it seems they are the only app affected.
Erektium: are there known problems with exavsync?
Erektium: like crashing etc
MrCooper: Erektium: yeah I think it has known issues
agd5f: oga: ?
spstarr_work: airlied: *awesome* many congratulations on the coming baby (today)!!!!!!!!
cire: Is there any development concerning the messed up mouse pointers? I am using Debian Lenny, so if it was fixed in CVS perhaps Debian did not yet use the new code... I'm just curious.
cire: or: is there a bug in somekind of bts where I can read about the development of this bug?
spstarr_work: I think airlied is on Fedora 11 tree now... if so i have to move to rawhide
wart: Hi there. What might several "invalid output device for dac detection"'s, followed by "(EE) RADEON(0): No connected devices found!", mean?
wart: (latest git HEAD)
airlied: wart: it means it couldn't find any connected devices,
airlied: the invalid output device is fine
wart: airlied: But the monitor is there, connected to the VGA port of the card :)
airlied: wart: yeah thats an issue :) can you pastebin the complete log?
airlied: wart: did it ever work?
wart: airlied: Sure thing. http://pastebin.com/m3e6251d7
wart: airlied: Nope, it never did :) In fact, benh fixed the things that were broken on my side just few weeks ago ;)
spstarr_work: airlied: are you on rawhide for dev or f10 still?
spstarr_work: airlied: *awesome* many congratulations on the coming baby (today)!!!!!!!!
spstarr_work: hey bridgman
airlied: spstarr_work: I'm doing both f10/rawhide
spstarr_work: but new stuff will be only in rawhide or you're backporting to f10?
spstarr_work: i can switch to rawhide
airlied: spstarr_work: depends, I'll probably backport fixes to f10
airlied: spstarr_work: so far I haven't really done much, I'm trying to get a DRI2 radeon going on rawhide
airlied: when I get a chance
EruditeHermit: the sky is falling!
spstarr_work: i'll go to rawhide because then i can test things fs waiting for backport (which adds time for you)
airlied: spstarr_work: I'll let you know when rawhide is working
airlied: at the moment its quite messed up I think
airlied: I'm just playnig with Intel kms first as I need to make upsteram work good.
wart: airlied: The system itself is quite strange. It's a modified IBM ppc64 (Cell) blade, with 64-bit PCI-E :) I seriously think I am the first one in the world trying to plug a video card in it :))
wart: (Nobody else is dumb enough, right).
airlied: wart: pastebin the full log and I'll have a look.
wart: airlied: I did :)
wart: 23:28 < wart> airlied: Sure thing. http://pastebin.com/m3e6251d7
airlied: wart: oops missed it :)
airlied: hmm I wonder is r600 endian safe
airlied: doesn't appear to be
wart: The BIOS itself is le. But benh's commits take care of it, don't they?
wart: At least, the driver right now groks the sizes and strings in rom just fine.
airlied: they do for r500, not sure how well tested they are for r600
wart: So you think we'd better try with something like x1800?
airlied: wart: care to test a patch?
airlied: wart: http://people.freedesktop.org/~airlied/r600_ppc.diff
wart: airlied: Of course! The only problem is that the hardware is in the other city, so I can't check the monitor screen :)
airlied: well I can tell by the log if it at least fixes the issue I can see
wart: Okay, just a moment :)
airlied: wart: however you might have further problems as I'm not sure we have swapper info for r600 released yet
airlied: I've no idea if you'll get correct colours even if it does start
wart: airlied: If I'll see the picture, just that is going to be a great success :))
wart: airlied: Patched one: http://pastebin.com/m209e9400
airlied: that looks much better
airlied: wierd its not picking up any DDC on the monitor thuogh
wart: The monitor there is quite an old CRT -- might be some problem on the other side :)
airlied: ah that would be the problem there then
airlied: so I would guess an x1x00 would have a better chance of not having messed up color.
wart: airlied: Okay. Thanks a lot -- I'll let you know tomorrow if we've got any picture on the monitor -- if you'll be around here, of course :)
mlankhorst: looks at topic
mjg59: mlankhorst: No?
mlankhorst: digs into compiling xorg from source again :)
bridgman: yeah, that was quite a split ;)
MostAwesomeDude: Sorry. Got a airhorn stuck in my throat.
mlankhorst: That's one down ;o
EruditeHermit: MostAwesomeDude: exciting times for radeon
EruditeHermit: your outburst is appropriate
mlankhorst: finally no longer in doubt whether the radeon was worth it :)
zhasha_netbook: Hello there my adversary, aka. MostAwesomeDude
EruditeHermit: tormod_: what happened to your xserver 1.5.99 packages?
tormod_: EruditeHermit: they were obsoleted by the official ones
MostAwesomeDude: zhasha_netbook: I'm your adversary?
MostAwesomeDude: What did I do?
EruditeHermit: be awesome
zhasha_netbook: MostAwesomeDude, nothing, I just want to be more like you but refuse to admit it
EruditeHermit: your alter ego as least awesome dude is his friend
spstarr_work: but, he is awesome
EruditeHermit: together you will rule the world
zhasha_netbook: if only <3
EruditeHermit: that is why he is your nemesis as MAD
EruditeHermit: that keeps you both in check
EruditeHermit: and the world remains safe
MostAwesomeDude: zhasha_netbook: If only you knew me, you might not want to be more like me. :3
EruditeHermit: MAD: that is true of anyone one could aspire to be
EruditeHermit: in the end if you had full knowledge, you would say no thanks
EruditeHermit: tormod_: in your 1.5.3 package which uses updated libdrm, did you backport mouse PPA? The mouse settings seem to be different
EruditeHermit: tormod_: secondly, if I wanted to try Xorg from jaunty, what all would I need? Mesa, server, specific driver and evdev?
zhasha_netbook: MostAwesomeDude, you're working on an LLVM backend for R3xx, that's all I need to know
zhasha_netbook: MostAwesomeDude, is there a rationale for not using C++ to code gallium?
ajax: the c++ abi still changes too much
ajax: and it's really awkward to write your app linked against one version of the abi but use a libGL linked against another version.
ajax: not impossible, just, really really not fun.
zhasha_netbook: is C declared "done" now?
zhasha_netbook: also the LLVM backends for gallium are written in C++
ajax: the C abi hasn't changed since, oh, 1994 or so?
ajax: whenever glibc 2.0 was.
MostAwesomeDude: zhasha_netbook: C++ is a bitch to get right.
MostAwesomeDude: We're only doing the
MostAwesomeDude: *the LLVM stuff in C++ because that's the language the rest of it's in.
MostAwesomeDude: Sure, some of Gallium would work in C++, but the overhead would not be good.
MostAwesomeDude: (And *somebody* would decide that using runtime_cast<> and exceptions is the right way to write drivers, and the rest of us would suffer for it.)
zhasha_netbook: I'm not trying to defend C++ here, but it's about as fast as C is, if not as fast to my knowledge. I'm just saying I just finished compiling the gallium documentation with doxygen and when I look at pipe_context what I see is a motherload of explicit self OOP function pointers
zhasha_netbook: basic overloading, but handled in the code rather than by the compiler
zhasha_netbook: I'm not saying it's in any way bad or evil, hell I like C. I'm just wondering if it was really the right language for the job. (truly noted exceptions are a pain in the arse)
bridgman: every driver team I have seen tends to move back and forth between C and C++ over a 3-4 year cycle. It's as predictable as the tides ;)
MostAwesomeDude: bridgman: IIRC the only reason Linux is still C is because nobody can convince Linus. :3
zhasha_netbook: MostAwesomeDude, why would they even consider rewriting it?
MostAwesomeDude: Okay, so I've got a serious question. I think the #dri-devel people that matter are in here already, so...
MostAwesomeDude: zhasha_netbook: People are C++ whores?
mjg59: MostAwesomeDude: Well, also because basically nobody wants to write any Linux code in C++
zhasha_netbook: I prefer applications being C. It simplifies the whole process, but sometimes C++ is the right language for the job
MostAwesomeDude: ...Okay. How should calling ABI look for pre-r6xx? No arguments; reserve a few registers always for arguments; use dedicated registers and clear them out whenever we want to call; something else?
bridgman: funny, I like applications in C++ and drivers in C...
tormod_: EruditeHermit: you should use the -evdev driver. For Jaunty packages, I would recommend installing Jaunty, otherwise add libdrm to your list.
zhasha_netbook: bridgman, it certainly depends on the application. No reason writing something that doesn't make use of C++ in C++
bridgman: maybe it's just because I don't have to write applications ;)
bridgman: so I don't mind other people using C++ ;)
spstarr_work: Jaunty...that just sounds wrong
spstarr_work: you know, Jaundice? ;)
zhasha_netbook: discussion for another day :P
zhasha_netbook: MostAwesomeDude, I actually have a question too. Actually I have a myriad of questions. In the end what I'd like to accomplish is now that I have this pretty netbook, set up my ATI (M54, r5xx) driven laptop with the necessary packages to code and test a gallium pipe and LLVM backend
MostAwesomeDude: zhasha_netbook: We currently have no pipe, which is much more important than LLVM.
zhasha_netbook: I find gallium isn't very newbie friendly :P
MostAwesomeDude: I have no idea how to write pipe. I've been out of the loop on the new CS way of doing BOs, and haven't had a chance to look at glisse's code.
zhasha_netbook: BO = buffer object?
zhasha_netbook: but is it even possible to test the pipe without an llvm backend?
MostAwesomeDude: Sure, just use fixed-function stuff.
zhasha_netbook: i thought that was converted to run on shaders as well
MostAwesomeDude: No, winsys can be told to do fixed-function instead.
MostAwesomeDude: I'm away from Radeon HW until the end of vacation. Fortunately LLVM doesn't need a Radeon to build.
zhasha_netbook: but in that case you're back to playing human debugger/verifier
Remosi: presumably LLVM can backend off x86 to do software rendering?
Remosi: hrm, although I guess that doesn't help with testing the r3xx backend
zhasha_netbook: good point, that would be how to do reference rendering, correct?
MostAwesomeDude: Remosi: That is one of the biggest points here. JIT SW shaders.
zhasha_netbook: I could use that if I am to mess with the pipe
zhasha_netbook: but first, I have no clue what I need to even get that far :P
MostAwesomeDude: zhasha_netbook: glisse has a working winsys; I think it's in his personal repo.
zhasha_netbook: I'd need a modified DDX driver correct?
MostAwesomeDude: Yep, and a new kernel module too.
zhasha_netbook: maybe I should just connect an external harddisk and install arch clean with nothing on it on that
zhasha_netbook: MostAwesomeDude, right now fglrx has decided that whenever I start X using it, it should produce a neat little kernel panic :P
MostAwesomeDude: zhasha_netbook: We don't have to do any RE.
MostAwesomeDude: Reverse engineering.
zhasha_netbook: oh no I know that. Just thought it'd clear up how messed up my current installation is :P
zhasha_netbook: orkid, what are you so happy about?
dmb: Bridgeman: whats the next thing to get released from amd :P?
MostAwesomeDude: dmb: Hopefully, docs.
dmb: MostAwesomeDude, oh, only sample code was released?
z3ro_: oh, I didn't realize there was code out yet
z3ro_: nice, the demo code shows a lot about how the CP packets have changed...
z3ro_: well, rather moved more to using packet3
z3ro_: cool there is some status debugging stuff too
z3ro_: so I guess the main thing now is to get some kind of minimal DRI driver working, then do a shader compiler
MostAwesomeDude: z3ro_: Not doing non-Gallium shaders.
MostAwesomeDude: Or, rather, *I'm* not doing non-Gallium shaders. :3
z3ro_: yeah I agree, this is probably a good point to move over to Gallium
agd5f: z3ro_: we have several in-house compilers we are working on getting released eventually (at least one)
z3ro_: nice :)
zhasha_netbook: z3ro_, as I understand it there will be a simple mesa driver for the r6xx, basic, like the r3xx driver. I think airlied is working on it
zhasha_netbook: and I doubt anyone will release GLSL enabled drivers for any radeon card before gallium sees the light of day for the first time
z3ro_: well, when I say shader I don't mean glsl in this context.
airlied: zhasha_netbook: nope not me, mhopf + ATI ppl.
z3ro_: shader as in hardware shader (binary instructions)
zhasha_netbook: isn't that core in mesa already?
zhasha_netbook: no wait, I'm confusing thing
zhasha_netbook: MAD is making an LLVM backend that does somewhat the same thing that needs to be done for the r300 mesa driver for shaders to work
Remosi: it sounds like a pretty awesome project
zhasha_netbook: once i watch jumanji in 720p and find an external harddrive of some sort, ill start looking into a pipe driver for gallium so we can actually use his llvm backend for something :P
zhasha_netbook: keep in mind that im completely new at this and itll take me 10 times longer than glisse to whip up something working
zhasha_netbook: is it possible to hack fbdev to load up an actual dri driver, and just have accelerated 3d but not 2d?
airlied: zhasha_netbook: not really.
zhasha_netbook: airlied, so if i were to try and create even a skeleton gallium driver, id still need to use the radeon ddx driver?
airlied: yes, thats what sets up the kernel
airlied: you'd probably need kms so it wouldn't be that much code in the DDX.
zhasha_netbook: yeah im about to install archlinux clean, with just an xserver and the necessities to toy with gallium
zhasha_netbook: compiling my own kernel seems perfectly reasonable
zhasha_netbook: is it included in 2.6.28 or do i have to patch it?
zhasha_netbook: airlied, are the modesetting bits separated from dri so much so that one can count on them not interfering with any 3d work?
dmb: should be :/
spstarr: oh nice /.
spstarr: here's the R3xx_3D_Registers.pdf i was looking for