bridgman: MAD; everything seems clean and well thought out; my snake oil alarm is ringing ;)
bridgman: tempted to try to find something with an i915 chipset and try it for real
bridgman: although I guess softpipe should be effectively the same
bridgman: it doesn`t *seem* the same, dammit ;)
ssieb: airlied: whenever you get this, it appears to be triggered by X getting interrupted by the mouse during a DRM call
ssieb: airlied: I can move a gimp window around using the keyboard and it's fine, but the same movement using the mouse hangs instantly
ssieb: airlied: I'll attempt to get a stack trace since I can repeat it so easily, but it will probably be the same as the one in the bug on the redhat bugzilla
bridgman: MAD; I assume someone has asked about the INSTRUCTION_EXT_NV token in TGSI
bridgman: I assume it`s not something only used on NV chips... cause that would get wierd
bridgman: but what else could nv stand for
MostAwesomeDude: bridgman: IIRC it's for NV-style condition codes. Predicated instructions.
MostAwesomeDude: It's only used in explicit nv shader assembly, so it's rather rare, but it required its own field in Mesa shaders and so TGSI has it too.
bridgman: but... but... I think all shaders need predicated instructions to be DX-anything these days
bridgman: oh, I see, those are conditional swizzles...
MostAwesomeDude: It's a specific NV-only shader extension. I can't remember what it's called.
bridgman: I guess what bothers me is I`m not seeing generic predication support, although
bridgman: there`s a CONDCODE destination register extension which might do it... I guess as long as we supress the destinatino register write it doesn`t matter if we execute the instruction or not... I guess..
bridgman: looks for the ATI gallium driver to see how all this works ;)
bridgman: looks like we just lost Australasia again...
bridgman: at least on dri-devel
bridgman: anyways, zzz time
bridgman: gotta get up early and scrape ice off the car ;(
johny: I'm on Ubuntu 8.10, using the radeon driver with DRI with Desktop Effects too. I'm experiencing an unusual CPU use when scrolling a page. This isn't so software-related as I managed to test, as even Dillo produces a high CPU use.
johny: Starting "glxgears" affects CPU in the same way as scrolling (about 100%)
x1250: johny, pastebin your xorg.conf, Xorg.0.log, and the output of $ LIBGL_DEBUG=verbose glxinfo
johny: x1250: This is Xorg. conf http://paste2.org/p/124870 . Xorg.0 log http://paste2.org/p/124883 . glxinfo http://paste2.org/p/124884
johny: x1250: Thank you for your time, interest. Please, let me know if you need any additional info.
x1250: johny, all looks ok to me. But, you could use: Option "AccelMethod" "EXA" in section Device in xorg.conf. Can you see videos if compiz is enabled?
x1250: what video card you got?
adamk_: glxgears spiking the CPU is not surprising. It's trying to get as high of a framerate as possible.
adamk_: But, yeah, switch to EXA :-)
adamk_: He has a mobility 9600.
johny: More precisely, 9700, which by lspci is seen as a 9600 01:00.0 VGA compatible controller: ATI Technologies Inc RV350 [Mobility Radeon 9600 M10]
johny: More precisely, 9700, which by lspci is seen as a 9600
x1250: I recall using radeon when on intrepid and thinking that performance was not that good. Things have changed in jaunty though. Maybe you could get a new version from GIT?
johny: x1250: Yes, I can see videos with compiz enables, but only with "xv" driver in mplayer, swithcing to "glx", messes up.
x1250: johny, EXA will fix that for you.
adamk_: I have no complaints with performance on Intrepid. I would definitely recommend trying EXA before updating from git.
johny: Can I ask briefly as a newbie, what exactly EXA is?
bigon: ubuntu use exa by default on their radeon driver
x1250: adamk_, maybe I was on software rendering :)
x1250: bigon, thats on jaunty, not intrepif
adamk_: There are different methods of achieving 2D hardware acceleration. The original one with modular XFree86 was XAA, but EXA is newer.
x1250: intrepid does not use exa by default
bigon: x1250: oh I tought it was also the case in intrepid
johny: Sorry for dumb question: Does it affect 3d acceleration in any way?
adamk_: johny: Nope. EXA requires DRM support to function well, but it doesn't impact 3D acceleration at all.
johny: That's good. I'm going to give it a try
x1250: johny, using EXA will fix your video playback troubles (totem, vlc, etc, closes itself) when using compiz.
johny: Is ii fine if I add it right like here
x1250: nope, thats bad
x1250: it should be:
x1250: Option "AccelMethod" "EXA"
x1250: including Option and the quotes
x1250: well, I haven't tried without the quotes, though :)
johny: So, that should be correct, right ? http://paste2.org/p/124892
x1250: it looks fine
johny: is going to fire up a rocket :)
johny: Be back soon to tell you how it went guys, thanks anyway!
johny: Hello there again :)
johny: Don't have word to thank you guys; There's been a huge improvement after enabling EXA
adamk_: Very cool.
johny: Yes, exactly. I finally can use a fully functional system, without lags, thank you again.
johny: adamk_: What does exactly EXA do?
adamk_: It's just another method of 2D acceleration. I honestly don't know how it works.
adamk_: It's the only way of getting hardware accelerated composite and/or render, as I understand it (on r300 and higher hardware).
johny: Is it new?
glisse: 2~3 years old, but it's useable only since few months
johny: Will be implemented in the newest Ubuntu release?
glisse: it's just a matter of enabling it, i think ubuntu will enable it by default in the future
x1250: johny, on jaunty is enabled by default, no need to do it by hand
johny: I'm not really eager to play around with fglrx, closed driver, I want to test the open-source one instead
johny: Just a curious question: Who exactly contributed in creating the "open" ATI driver?
glisse: johny: many people, it's an old drivers
johny: Has ATI had anything to do with the whole process? I bet, no...
glisse: they helped in the past, and now the help again
x1250: there are 2 opensource drivers, x86-video-ati and x86-video-radeonhd, so you can search on google if want more info
glisse: i guess people should use their work email so commit can reflect that :)
x1250: there are some articles out there
mikkoc: glisse: hi, have there been any progress on those random hard lockups with r500? i still have them :(
z3ro: johny: amd are releasing docs and code now, so they are very helpful. :)
mikkoc: especially when the cpu is under stress
z3ro: before ati was brought by amd, the only docs were r200 given under NDA to some developers.
johny: But, is the driver officially firmed or they help only still staying behind the whole community?
z3ro: johny: firmed? I don't understand?
ech0s7: working DRI on rv620 with radeonhd ??
z3ro: ech0s7: not yet
ech0s7: z3ro: but i have direct rendering on
johny: I mean released officially by ATI?
ech0s7: z3ro: and i have glxgear that works
x1250: ech0s7, maybe software rendering?
z3ro: johny: radeonhd was funded by amd (at least for the initial development)
z3ro: johny: but many people from different companies work on the drivers (either just for fun, or for their employer)
ech0s7: x1250: i don't know
ech0s7: but compiz doesn't works
ech0s7: i get white screen if i load fusion-icon
johny: Thus, as soon as it gets to the final stage, will they release it ?
adamk_: ech0s7: You are undoubtedly using the software rasterizer.
z3ro: johny: the driver is released now.
z3ro: johny: google xf86-video-radeonhd
adamk_: ech0s7: It will show direct rendering, but doesn't provide hardware acceleration.
ech0s7: ok... i understand
ech0s7: when it works ?
z3ro: johny: there is also xf86-video-ati which is an older driver, before radeonhd was written. it was written by the community (and the docs also helped here0
x1250: ech0s7, what distro are you in?
johny: z3ro: I'm googling it indeed.
ech0s7: x1250: archlinux
ech0s7: why ?
z3ro: heh I guess there is a nice opportunity for phoronix to write a history article, if they haven't already. ;)
x1250: they have one :)
z3ro: johny: there you go, some background reading for you. :)
johny: z3ro: I'm reading about EXA for now
ech0s7: when hardware acceleration will works on rv620? do you know?
glisse: mikkoc: i will take a look again at this soon
mikkoc: oh cool, thanks
glisse: got some new idea to make reset work
MrCooper: z3ro: actually, large parts of the radeon driver were also funded or written directly by ATI back in the days
z3ro: MrCooper: ok, I didn't know that. :)
ech0s7: good evening
ech0s7: when hardware acceleration will works on rv620? do you know?
mjr: it's time to look into the future, all the way to the year 200
jcristau: ech0s7: when it's ready
ech0s7: jcristau: a prevision ?
jcristau: what i said
ech0s7: jcristau: it isn't a real answer, but a sarcastic response
adamk_: It's the only answer that can be given.
adamk_: open source development almost never follows a timetable.
ech0s7: adamk_: why ?
bridgman: ech0s7; we released initial acceleration code for 6xx/7xx during the holidays; Xv still needs some debugging, and EXA could use some optimization, plus there's all the usual teething issues with new code, but for 2D I think we're really close. The code is out in public repositories so shouldn't be long
ech0s7: ah ok...
bridgman: 3d will be a bunch more work
ech0s7: ok ok.. thanks
bridgman: hopefully first 3d acceleration (glxgears) will be this month, at least that's what the devs are hoping
ech0s7: where can i get all news ?
ech0s7: www.x.org/wiki/radeonhd it's the right page ?
adamk_: Everytime you say something like that, it ends up on the phoronix forums as "Full 3D acceleratin will be this month" :-0
adamk_: :-) rather
ech0s7: adamk_: i haven't never wrote on phoronix :)
bridgman: if you want to watch one spot Phoronix is probably the best; there's also an aggregator on freedesktop.org that pulls together a number of developer blogs but the name escapes me right now
bridgman: of course, now I remember ;)
spstarr_work: hullo bridgman
spstarr_work: lunch? :)
bridgman: just heading into the office now; was working from home, would tomorrow be ok ?
spstarr_work: bridgeman: Sure, sounds like a plan.
spstarr_work: hullo MAD
said: hi guys! can someone help me to configure driconf in the right way with my 9200 pro?
adamk_: said: What's the problem you are having?
said: adamk_: freeze
adamk_: Your system is freezing completely? What are you doing when this happens?
said: just xorg freeze (music continue to play) and i can't reboot xorg with ctrl+alt+back
said: it happends when i use vlc or play quake 3 arena
adamk_: I doubt that anything you can change in driconf is going to fix that.
adamk_: Hey, can anyone here kick-ban Thargor till he fixes his connection?
adamk_: said: Does even glxgears cause this lockup?
said: uhm no.. but it can happend after a long time
said: so maybe yes
adamk_: Well I'd guess that this is either a driver bug or a hardware failure.
adamk_: What distribution are you using?
said: arch linux
adamk_: Can you go to http://pastebin.com and paste in your /var/log/Xorg.0.log file as well as the output of 'glxinfo' ?
said: also my xorg.conf?
adamk_: said: Your running at AGP 8x. There are some problems with different AGP chipsets, sometimes.
adamk_: said: You could try forcing the radeon driver to run your card at 1x to see if that solves the problem. If so, you could even try increasing it to 2x or 4x.
adamk_: You would add this line to the Device section of your xorg.conf file:
adamk_: Option "AGPMode" "1"
adamk_: I'm not sure this will fix your problem, but it's worth a shot.
said: before i was using the agpmode 1 and it crashed anyway
adamk_: said: Have you tried disabling color tiling, page flipping, or even setting the card to PCI mode?
said: before i used the default configuration (without specify anything). How to set the pci mode?
adamk_: Option "BusType" "PCI"
mjg59: Huh. D3ing an X1900 doesn't seem to result in any significant decrease in power draw
adamk_: said: You should check out the 'radeon' man page.
said: but i use the agp, not the pci
adamk_: Right, but there might be an issue with the AGP driver.
said: ok thanks a lot!
said: if a specify pci mode, agpmode doesn't matter?
said: ok, there are other configurations i shoud try?
adamk_: Like I said, you can try disabling color tiling and page flipping.
said: ok but I read that these options are advised for my card
adamk_: Right... But that doesn't mean they will always work correctly for every single person.
adamk_: All I'm suggesting is that you disable them to see if that fixes your problem.
said: ok, I'll try for sure
said: thanks a lot again!
soreau: Thargor: Having trouble? :)
rmh3093: airlied: ping
MostAwesomeDude: Wow, Gallium code *is* easy.
bobbens: does that mean you already finished the gallium3d driver for r3xx? :)
MostAwesomeDude: No. That would imply that I'm a capable coder. :3
MostAwesomeDude: I started, though.
MostAwesomeDude: I can see it now...
MostAwesomeDude: Phoronix: R300 Gallium Driver Almost Ready: neither compiles nor segfaults
TobiasTheCommie: gives MostAwesomeDude some spice
TobiasTheCommie: damn phoronix is fast
MostAwesomeDude: Says programmer Corbin Simpson: "Hey, man, I just started. What the hell?"
MostAwesomeDude: Seriously, I swear he's got a hook for when people commit to git.
TobiasTheCommie: oh, heh, i thought you were series on that phoronix quote
MostAwesomeDude: Not that there's anything wrong with that. :3
bobbens: it wouldn't surprise me :)
bobbens: i'm looking forward to it :)
MostAwesomeDude: Nope, was joking. See http://www.phoronix.com/scan.php?page=news_item&px=Njk1OQ
bobbens: but it's doing quite a good job :)
bobbens: only the ever-annoying valgrind hardlocks
bobbens: that's my fault for not debugging though :)
TobiasTheCommie: read that yes :)
PWMx: Is "Gallium Driver" the LLVM back end ? And is it Turing-complete with R6/700 ? (And not with R300 ?!) Would the back-end accept any front end ? (I guess those could be TGSI, OpenCL /ES & C /++ ;-)
MostAwesomeDude: PWMx: One at a time, I'm a slow typist. :3
MostAwesomeDude: spstarr_work: It was a joke...
ajax: Phoronix: Sup dawg, I heard you like compiling.
MostAwesomeDude: PWMx: The idea is that we have both LLVM backends and Gallium drivers. The Gallium driver can call LLVM when it needs to.
MostAwesomeDude: And IIRC R600's shader engine is a complete arch in the more traditional sense. R300's is not, but is still capable.
MostAwesomeDude: And yes, ideally, any LLVM/Gallium (call it Gallivm) frontend could be compiled.
MostAwesomeDude: First up is GLSL, but I totally expect CUDA, Brook+, OGL VG, etc.
MostAwesomeDude: Eventually. First things first. "Wiggle your big toe."
MostAwesomeDude: ajax: Number one excuse for slacking off, innit? :3
PWMx: So it's like : Gallium driver -> TGSI -> TGSI_LLVM FE -> LLVM & -bytecode -> Rxx_LLVM BE -> native GPU ?
MostAwesomeDude: PWMx: Two paths. One for shaders, and one for everything else.
MostAwesomeDude: Shaders -> Gallium frontend -> Gallivm -> LLVM -> winsys -> HW
MostAwesomeDude: Everything else -> Gallium frontend -> pipe -> winsys -> HW
MostAwesomeDude: Still not sure if shaders need to go through the pipe.
bobbens: totally looking forward to GLSL with radeon :)
PWMx: Isn't the pipe more about state tracking etc. housekeeping ? So the code would go via LLVM ?
MostAwesomeDude: Meh, just pulling apart the pieces that used to be fused together in Mesa.
MostAwesomeDude: PWMx: There's a module called CSO that does most of the tracking, and frontends above it. The pipe is for setting up HW state, and is actually the nominal place to compile shaders.
MostAwesomeDude: We're only moving shaders to LLVM. There's no reason to have anything else over there.
PWMx: I'm bit confused (as you probably already noticed) .. Why two 'universal' intermediate presentations : TGSI & LLVM bytecode ? Possible to skip one (if needed) ?
MostAwesomeDude: Maybe someday. But some frontends generate TGSI directly. Check out the XvMC frontend.
PWMx: Yes, those would need the support for TGSI as it is part of the interfacing / abstraction layer ..
MostAwesomeDude: The big idea behind the TGSI -> LLVM IR is that some backends (i915, i965) don't have LLVM support (planned), and some backends (X86, PPC) need different kinds of LLVM IR to go fast.
PWMx: OK. Just been thinking how, let's say OpenCL, would be implemented (in parallel with OGL) with this Gallivm .. And the re-use of different FEs & BEs (mix'n'match?)
MostAwesomeDude: Yeah, the idea is that everything that's reusable should be reused and that separation of front and back parts is essential.
PWMx: I think there already is (experimental) OpenCL FE up and running. I'm not sure if it's public yet .. (So I won't say much more ;-) )
MostAwesomeDude: I'm waiting for somebody to do a D3D frontend, TBH. Couldn't care less about OpenCL. :3
PWMx: I'm still wondering how, let's say LLVM_GCC FE and R300 BE (or even R6/700 BE) would fit together .. Surely there would be some mismatch ? (Especially if the BE target isn't Turing-complete !)
MostAwesomeDude: The backend's Turing-complete, just not in the normal way you'd expect. :3
MostAwesomeDude: And no, the backend would probably just barf on you.
PWMx: Readback and multipass ?
MostAwesomeDude: Possible, but currently not there.
MostAwesomeDude: Actually, currently, there's *nothing* there.
fir3_: i'd like to buy a new gpu(agp) for an amd athlon xp2800+,1gb ram system, it should be have good performance in games like ut3/quake wars with an opensource driver. which one would you recommend?
chithead: I don't think quake wars runs very well with the open source driver
z3ro_: chithead: iirc it won't run at all
agd5f: fir3_: buy pcie if you can. agp is trouble
PWMx: Well, you must have plans .. And good plans already get you half way there (as they say). (And sometimes replanning twice skips the hard work altogether :) )
z3ro_: (although I tested a while ago, so ymmv)
fir3_: agd5f: i don't have a pcie slot in that system :/
PWMx: SO the early BE wouldn't completely support the LLVM bytecode ? How to handle ?
fir3_: any estimations when an open driver will fully support the newer gpus?
z3ro_: fir3_: fully support is a hard question to answer...
z3ro_: I ***guess*** we'll have basic 3d within a few months.
z3ro_: full features will take gallium and a memory manager
z3ro_: and a lot of work
z3ro_: then there's optimization (though this may be easier with newer hardware as it's more dependant on generating good shader code than weird register hacks)
z3ro_: that being said, generating good code is not easy
fir3_: how long will it take at least to make qw/ut3 playable?
z3ro_: they need the advanced features which depend on memory management.
z3ro_: so no idea really, but not real soon.
fir3_: 1 to 1.5 years?
z3ro_: hopefully shorter
z3ro_: but I really hate giving time estimates, because 1. I'm not activly working on this stuff at the moment, and 2. it usually gets taken as "we will, without question, have it by
z3ro_: rather than "we estimate, that all going well, we'll have it by
MostAwesomeDude: And it never all goes well.,
z3ro_: true, and then there's real life to consider, which always finds a way to get in the way.
fir3_: doesn't amd also pay someone to work on the driver? like intel
z3ro_: on fglrx? no idea, but yeah, they probably license a lot of code from other companies.
z3ro_: you'd have to ask amd about how fglrx is developed, and I doubt they would tell you.
fir3_: i mean the radeon driver
otaylor: fir3_: both intel and amd pay people to work on open source graphics drivers. intel's team is considerably larger, though.
ajax: a fair chunk of fglrx is derived from the old sgi sample implementation
ajax: but i suspect that's quite a minority of the code by this point
z3ro_: ajax: I would guess just the gl function dispatch stuff probably.
ajax: more that just that, if memory serves. but i'm trying to delete those memories, they're mostly painful.
z3ro_: ajax: haha, vodka ftw! ;)
ajax: i'm more of a bourbon man myself, but any port in a storm.
agd5f: at this point fglrx shares a lot of code with the windows driver
fir3_: so will it ever be possible to support gpus with an open driver at the time when they are available? :o
agd5f: it's a lot easier to leverage one stack across OSes than to develop two drivers
ajax: fir3_: before a massive market shift such that open source is the dominant OS? no.
fir3_: (not just the basic functions though)
ajax: the only people for whom free software support is a ship requirement is the CPU vendors, and they've got the advantage of already having the support in place.
fir3_: are there too less devs or is this stuff just too complex?
MostAwesomeDude: fir3_: Possible? What ajax said. Feasible? No, not without more dev time.
z3ro_: fir3_: I think the best we can hope for is a simultaneous product release and documentation release.
z3ro_: which imho would be ideal
agd5f: fir3_: not enough devs and it's very complex
z3ro_: also once we have the new infrastructure setup (eg gallium etc) it becomes easier to support new hw.
MostAwesomeDude: OTOH there's a big gap between release and mainstream uptake. For example, the kernel's ath9k driver is officially blessed by Atheros and has been mainlined before its cards have become common.
chithead: OTOH for atheros usb cards which have been on the market for a long time already there is only a driver in a very early stage of development
MostAwesomeDude: Yes, but there were major problems with getting docs released not unlike ours.
agd5f: it normally wouldn't take quite this long, but we are catching up on like 5 years of GPUs in the last year, things should get better
z3ro_: I think the FCC is pretty far up the ass of wireless hardware manufactures.
MostAwesomeDude: z3ro_: There's stuff on video cards, too. Macrovision, AES, UVD, etc.
z3ro_: but usually that can just be ommitted from the docs
PWMx: There is changes happening on embedded world - and especially mobiles .. All are moving towards OSS and thus also HW vendors get the push.
z3ro_: not so with wireless chips
agd5f: the basic r3xx design carried though several generations of chips (r3xx, r4xx, r5xx). same is true of r6xx. once we get r6xx support, r7xx mostly just works, etc.
z3ro_: you have to do all that power regulation crap
z3ro: speaking of wireless... damn unreliable connection. =/
MostAwesomeDude: Hm. Looks like there's still some stuff in the winsys that need to be moved upwards, but otherwise, looks pretty solid. OTOH I barely understand the DRI/DRI2 handshake, so it could be completely bogus.
fir3_: so if i want a fully(games) working oss driver as fast as possible, the radeon3*** series would be the best choice?
z3ro: fir3_: well probably r5xx and 6xx are going to get the most work in the near future, but once we get r6xx 7xx won't be far behind
chithead: fir3_: 3d is supported by oss drivers up to radeon x1950
z3ro: yeah if you want something that works right now, get r5xx
z3ro: but note we still don't have the stuff that needs MM there, so no FBO etc
z3ro: and no GLSL
fir3_: how is the performance compared to the win driver?
fir3_: any benchmarks?
z3ro: fir3_: phoronix no doubt has some article. :P
fir3_: i never saw benchmarks of the drivers on phoronix :/
z3ro: I'm sure they did some article...
fir3_: you mean this one? http://www.phoronix.com/scan.php?page=article&item=ati_r500_gaming&num=1
z3ro: fir3_: yeah but I thought they had some graphs too
z3ro: shrugs. maybe I'm misremembering.
m03sizlak: rofl, anyone see this bug: "xorg-x11-drv-ati-6.9.0-65.fc11 serious issues (including hardware damage)"
MostAwesomeDude: m03sizlak: Huh, interesting. I wonder if his card's in working shape; sounds like he's got issues.
m03sizlak: hrm i have this issue i think: http://lkml.org/lkml/2008/12/13/77
m03sizlak: anyway i can build xorg-x11-drv-ati myself somehow ith 1 patch reverted?
m03sizlak: or would i need all of the x sources?
z3ro: MostAwesomeDude: just checkout the xf86-video-ati tree from fd.o and do: git revert
z3ro: damn tab completion. :P
z3ro: m03sizlak: ^^
m03sizlak: i see
MostAwesomeDude: No worries.
m03sizlak: 6.9.0 or 22.214.171.124 ?
agd5f: m03sizlak: you'll need to use the fedore sources as that stuff isn't upstream yet
m03sizlak: ah, finally got it compiling
m03sizlak: hopefully reverting radeon-6.9.0-remove-limit-heuristics.patch will fix this. it annoying the fsck out of me
m03sizlak: drmmode_display.c:249: error: too few arguments to function 'xf86CrtcRotate'
ssieb: ok, this X hanging is driving me nuts, and my poor wife keeps telling me the computer is frozen...
ssieb: thinks he may need to switch to the fglrx driver for a while :-(
m03sizlak: ssieb i have same prob
phantomas: anybody know a videocard that is fanless and has displayport
phantomas: what is better? ATI RV610 onboard chip or radeon hd 2400 chip
chithead: phantomas: ati firemv 2260, also several 780g mobos have displayport
phantomas: what is the difference between 780G and 780V
rx__: V is value
chithead: iirc 780v has lower clock speeds
Wizball: what is the difference between 780G and 780V
chithead: iirc 780v has lower clock speeds
Wizball: chithead for onboard video?
chithead: Wizball: or maybe not. find amd's specifications here http://www.amd.com/us-en/0,,3715_15532_15533,00.html
Wizball: chithead thanks good link
Wizball: why is intel more popular these days when amd offers better solution
moeSizlak: well, just compiled -65 with commit 5c5736604e6a1bc280821bd92f3714e0c9e7d7d3 reverted, as suggested to fix random hang problem
moeSizlak: got an error, too few arguments to xf86CrtcRotate which was caused by radeon-mode-fix-rotate.patch...so i reverted that one as well
moeSizlak: now time to see if i can get this thing to hang
MrCooper: for the record: a Gallium driver can work without LLVM - in fact, all drivers can so far. I think the plan is mostly to use LLVM for optimization purposes
MostAwesomeDude: MrCooper: Bingo, except I'm really not wanting to write a TGSI assembler.
MostAwesomeDude: I mean, I suppose I will, but I'm not going to enjoy it. >:3
MrCooper: it's probably a faster way to a basic working driver than an LLVM backend...
MrCooper: anyway off for tonight, bbl
ssieb: moeSizlak: any luck?
MostAwesomeDude: glisse: You were talking about how the CS style of sending stuff is kinda like batchbuffering in the Intel driver. Any hints on that? I'm almost done with the easy stuff (screen, context).