05:20 Aman: Hi all
07:12 karolherbst: pmoreau: the mmiotrace fix got upstreamed
07:17 jayhost: karolherbst glmark2 no change - freq change - mem change : http://pastebin.ca/3388312 http://pastebin.ca/3388314 http://pastebin.ca/3388317
07:18 karolherbst: :D
07:19 karolherbst: more than 6x faster
07:21 pmoreau: karolherbst: \o/ Well done!
07:22 jayhost: profit
07:22 karolherbst: pmoreau: do you also have those DirectMap2M and DirectMap1G entries inside /proc/meminfo?
07:23 pmoreau: karolherbst: 2M yes, but not 1G
07:23 karolherbst: mhh
07:23 karolherbst: well I have also 1G, but oddly only after a fresh boot it is bigger than 0kB
07:23 karolherbst: after some time it slowly drops to 0
07:24 karolherbst: but I think these are the ioremaps currently used, not sure though
07:33 karolherbst: ohhh... fun times, I thought I do something wrong, but than push; pop; corrupts the heap...
07:33 karolherbst: makes sense
07:50 Yoshimo: is http://workupload.com/file/5sC8LzCj already in the vbios collection?
07:54 karolherbst: ......
07:54 karolherbst: Yoshimo: ohhh maybe?
07:55 karolherbst: stupid flex
07:55 karolherbst: now my include works and I just added a \n in front of the buffer...
07:57 karolherbst: Yoshimo: we have tons of fermis though already
07:59 karolherbst: its working1...
08:00 Yoshimo: just trying to help
08:00 karolherbst: Yoshimo: yeah I know
08:05 karolherbst: I got shading_language_include to work :)
08:06 karolherbst: imirkin: I have some "error: linking with uncompiled shader" errors, any special way to track them down?
08:07 karolherbst: I would expected something like "linking with uncompiled shaders: 163" or something to be printed :/
08:33 karolherbst: mhh odd
08:34 karolherbst: I have glCompileShader(216); glCompilerShader(234); glAttachShader(235, 216); glAttachShader(235, 216); glLinkProgram(235) and the latter fails with "warning: error: linking with uncompiled shader"
08:53 karolherbst: odd, glShaderSource(shader = 216, count = 1, string = [6BB0788BA6DFF7F4204CCFE5139E8AE6], length = [-1])
09:59 karolherbst: yay!
10:00 karolherbst: Tom^: divinity running on mesa :)
10:14 imirkin: karolherbst: could be part of the shader caching ext? dunno
10:14 imirkin: try to see where that string comes from
10:24 karolherbst: imirkin: yeah I also was thinking of that
10:25 karolherbst: imirkin: thing is, with mesa it also sets the source to that :/
10:26 karolherbst: ohh it is inside the game binary...
10:27 karolherbst: ohh wait no, it was the trace
10:27 karolherbst: imirkin: Data/GLSLShaders.pak
10:27 karolherbst: all are there
10:27 karolherbst: and there are like 50 or something
10:27 karolherbst: so yeah, the game has those strings already
10:28 karolherbst: but I am actually relieved that the game only needs shading_language_include and that's all :)
10:29 imirkin: karolherbst: no idea what that could mean... maybe it's a cooked shader in the blob that they identify via that hash
10:29 karolherbst: yeah most likely
10:29 karolherbst: if I simply return in glShaderSource after getting those, it just runs fine
10:29 karolherbst: mesa invalidates those shaders otherwise and linking fails later
10:30 karolherbst: but the source is attached earlier
10:30 karolherbst: performance is quite good otherwise though
10:38 karolherbst: VK_NV_glsl_shader added to vulkan :D now the fun really starts
10:38 imirkin:waits for GL_ARB_shading_language_spirv
10:39 karolherbst: maybe vulkan should stay within mesa in the end, or does anybody want to put the glsl parser into a seperated library?
10:42 karolherbst: I am sure this will be added to GL 5.0
10:43 mooch: is gl 5.0 even going to happen?
10:44 karolherbst: of course
10:44 karolherbst: OpenGL is suited for simple projects where call overhead isn't important
10:44 mooch: well, opengl has programmable blending right now, whereas vulkan does not
10:45 mooch: this is important for some applications, such as pcsx2
10:45 karolherbst: is there an issue opened for that?
10:45 imirkin: i'm guessing that the people who wrote vulkan knew about blending
10:47 karolherbst: how could I dump the shaders for shader-db again?
10:49 karolherbst: ST_DUMP_SHADERS was it, right
10:54 karolherbst: imirkin: ohhh ST_DUMP_SHADERS only dumps the shaders before they got parsed? :/
10:58 pmoreau: karolherbst: Ah ah ah, I like your reply on the forum! :-D Some people are just always complaining.
10:58 karolherbst: :D
11:00 suroi: anyone in here to solve a libgl related problem?
11:00 karolherbst: nah, being a hero sucks
11:02 suroi: agreed, but i've been at a loss of what to do for a week
11:02 karolherbst: whats the problem?
11:02 suroi: trying to get 32 bit lib gl to work nicely with nouveau
11:03 karolherbst: do you use the 32bit packages of your distribution?
11:03 suroi: it's for steam
11:04 karolherbst: ahhh
11:04 suroi: running 64 bit arch
11:04 karolherbst: yeah, this is a known issue
11:04 karolherbst: you have to remove something from the steam_runtime
11:04 karolherbst: but I always forget what
11:04 karolherbst: (and sometimes from games)
11:04 suroi: really wanted to try out nouveau for a while and since the newest version of the arch nvidia package fucked itself, went to try nouveau
11:04 imirkin: libstdc++.so.6
11:04 karolherbst: right
11:07 suroi: wait i don't think this solves the general problem that glxinfo23 fails out
11:08 karolherbst: then something else is messed up
11:08 karolherbst: LIBGL_DEBUG=verbose glxinfo32
11:14 mooch: imirkin: is it possible to do something like an mmiotrace on windows?
11:15 suroi: https://s3.amazonaws.com/raw.paste.esk.io/zSXx/m-83a?versionId=rkAatOmgucg54yNLptM5_XvNidsuu72w
11:16 karolherbst: suroi: I bet nvidia is loaded
11:17 suroi: https://s3.amazonaws.com/raw.paste.esk.io/DqVl8xHT_A?versionId=ZbMrT6m2Nm0RudB2od8YWQacgNRe.b_w
11:17 imirkin: suroi: it looks like you don't have AIGLX
11:17 imirkin: pastebin xorg log
11:17 imirkin: (does 64-bit glxinfo work?)
11:19 suroi: http://pastebin.com/XFQWj8gF
11:19 suroi: it does
11:19 imirkin: you might also try using "strace -f -e open" to figure what all it's trying to load and if anything's failing
11:19 imirkin: hm yeah, that stuff all looks fine
11:20 suroi: i'm pretty stumped
11:20 imirkin: check the strace
11:20 imirkin: i.e. strace -f -e open glxinfo32
11:20 suroi: what do you want me to attach to?
11:20 suroi: k
11:21 suroi: http://pastebin.com/FD2i6HQg
11:21 imirkin: open("/usr/lib32/libGL.so.352.21", O_RDONLY) = 3
11:21 imirkin: that seems unfortunate.
11:22 imirkin: open("/usr/lib32/tls/libnvidia-tls.so.352.21", O_RDONLY|O_CLOEXEC) = 3
11:22 imirkin: etc
11:22 suroi: oh neat
11:22 imirkin: your 32-bit libGL appears to point to blob
11:23 imirkin: [needless to say, this won't work with blob]
11:23 imirkin: er, with nouveau
11:23 suroi: right
11:24 suroi: strange that it would use that instead
11:24 suroi: i've scraped all nvidia packages out
11:24 imirkin: apparently not hard enough?
11:24 suroi: pacman -Qs nvidia returns libvdpau and the xf86-video-nouveau package
11:24 imirkin: anyways... not much i can say other than strace doesn't lie :)
11:25 suroi: computers don't lie
11:25 suroi: humans just make a lot of assumptions
11:26 imirkin: PEBKAC, as it were...
11:26 imirkin: the rest is determing which keyboard and which chair...
11:27 pmoreau: suroi: I have been having some troubles with pacman while switching between Mesa and nvidia-libgl, where it didn't removed all the files (for some reasons)
11:27 suroi: imirkin: CODE 10keyless, and some shitty $55 walmart office chair
11:28 suroi: pmoreau: any insight on a nice clean way to remove those lib/references?
11:29 pmoreau: suroi: You can try resintalling the packages, and it will complain about some files still being there. Remove those, and then reinstall mesa-libgl and lib32-mesa-libgl. Not the cleanest way to do it, but…
11:33 suroi: that's pretty saddening
11:34 imirkin: sounds like the problem is between some arch person's keyboard and chair :)
12:08 karolherbst: set ftz u8 $p0 lt f32 $r63 $r5
12:09 karolherbst: can $r5 be below 0 here?
13:05 Jayhost: karolherbst ahh, doom 3 runs fine with soft shadows off.
13:08 karolherbst: Jayhost: with nouveau?
13:09 Jayhost: yes
13:10 karolherbst: is this through wine?
13:10 Jayhost: It is not.
13:11 Jayhost: It is package RBdoom3bfg with data files put in .rbdoom3bfg/base
13:12 karolherbst: ahh
13:16 Jayhost: karolherbst Is there anything I can do or does Nouveau have anything deemed important in roadmap.
13:17 karolherbst: find issues
13:17 karolherbst: well
13:17 karolherbst: maybe on trello is somehting you like to do
13:17 karolherbst: but best would be you find something which is bothering you most and fix it :D
13:48 Jayhost: Personally, I'm really excited to run free bios, free software while taking no real losses. Ideally others should have the same experience if they care to.
15:34 imirkin_: Jayhost: i've been unsuccessfully trying to sucker someone into finish tessellation support on maxwell
15:35 imirkin_: Jayhost: that would get maxwell up to the same GL 4.1 as the rest of fermi+
15:36 karolherbst: imirkin_: I finally found a use of my "sub(a, 0) to a" opt
15:36 karolherbst: 33 shaders from divinity
15:55 Jayhost: imirkin. Alright. I'm reading up on it.
15:57 imirkin_: Jayhost: it's mostly done... just need to figure out how to deal with tess control outputs
15:57 imirkin_: i have some mmt traces in https://people.freedesktop.org/~imirkin/traces/gm107/
15:57 imirkin_: someone just has to figure out how that shader code is working, mapping it back to the original glsl
15:58 imirkin_: (which you can find in https://cgit.freedesktop.org/piglit/tree/tests/spec/arb_tessellation_shader/execution
15:58 imirkin_: tbh this is a hard task
15:58 imirkin_: there's a reason i punted on it.
15:59 imirkin_: if i had the hw locally, i bet it'd take me at least a full day of banging my head against the wall before i figured it all out
15:59 imirkin_: for someone inexperienced in (a) tess, (b) nouveau... i'd guess... probably a few weeks up to a month.
16:06 Jayhost: I imagine the best way to learn is seeing how it's done on other hardware
16:07 imirkin_: nope
16:07 imirkin_: you need to figure out how it's done on this hw
16:07 imirkin_: maxwell is different from kepler/fermi, for example
16:07 imirkin_: (not *that* different, but a little different...)
16:14 Jayhost: Okay
16:30 pmoreau: Great, the get-global-id example is working on GK106. (just need to figure out why the generated cvt (from u32 to u64) was invalid)
16:30 pmoreau: Now, why is the vec-load example failing…
16:30 karlmag: hmm
16:30 imirkin_: pmoreau: there's approximately a 100% chance that emission for 64-bit ints is broken somehow
16:30 karlmag: checking the GLIBC_VERSION version... unsupported version 2.23
16:30 karlmag: configure: error: Valgrind requires glibc version 2.2 - 2.19
16:31 imirkin_: pmoreau: double-check it in nvdisasm
16:31 karlmag: (curiousity got to me, but I seem to fail at that step)
16:31 imirkin_: karlmag: don't need that to look at mmt traces, just record them
16:32 pmoreau: karlmag: Yeah, that's on my todo list fo the week-end. Mostly, just copy paste the "code" for glibc 2.22 in the configure
16:33 karlmag: imirkin_: possibly.. I wouldn't know :-)
16:33 karlmag: I would guess demmt (and friends) is also in there somewhere?
16:33 pmoreau: imirkin_: I got an invalid opcode error message from the card, so it didn't like the emission. It could highly be that my code generation was wrong in the first place.
16:34 imirkin_: karlmag: demmt is in envytools
16:34 imirkin_: pmoreau: yeah... nothing uses 64-bit ints in the GL path
16:34 imirkin_: support for them is pretty half-hearted
16:34 pmoreau: :-)
16:35 imirkin_: there's now a GL_ARB_gpu_shader_int64, but i'm waiting for airlied to pipe it through to TGSI before acting on it
16:36 pmoreau: Sounds reasonable
16:38 pmoreau: How do you generate the file to feed to nvdisasm?
16:38 imirkin_: perl -ane 'foreach (@F) { print pack "I", hex($_) }' > tt; nvdisasm -b SM30 tt
16:39 pmoreau: Thanks!
16:43 pmoreau: nvdisasm: "I2I.U64.U64 R0, R4; /* 0x1c00000011b01c04 */", envydis: "11b01c04 1c000000 cvt u64 $r0d ??? $r4 [unknown: 01800000 00000000] [unknown operand]"
16:43 imirkin_: that's wrong right?
16:44 imirkin_: that should be I2I.U32.U64 no?
16:44 pmoreau: Depending if it's I2I.src.dst or I2I.dst.src, but yeah, it shouldn't be twice U64
16:45 pmoreau: (Though it does a I2I.U32.U32 just before that, and it does not complain about it)
16:45 imirkin_: the real question is why envydis complains... looks like it should decode...
16:46 imirkin_: oh i see
16:46 imirkin_: yeah that's wrong
16:46 imirkin_: pmoreau: can you pastebin the NV50_PROG_DEBUG=1 output?
16:46 pmoreau: Sure
16:47 pmoreau: Only 1? Not 255? :-D
16:47 imirkin_: just the 1 :p
16:48 karlmag: imirkin_: just one more stupid n00b question before I go to bed; which of that execution test code does the gm107-tess-quads.mmt map back to?
16:48 imirkin_: karlmag: quads.shader_test
16:48 imirkin_: karlmag: start with the other one... quads is more complicated
16:49 karlmag: ah... ok...
16:49 karlmag: well, I just tried to understand where stuff was coming from at first
16:49 pmoreau: imirkin_: https://phabricator.pmoreau.org/P94
16:50 karlmag: there where two other files it could have been too it seems. And also; I'm would probably be waaaay over the top of my head in any case wrt this stuff, to be honest.
16:50 pmoreau: It's a good exercise to try to run my code on different hardware. Found a couple of bugs that I was
16:50 pmoreau: s/was/wasn't hitting on Tesla
16:50 karlmag: But poking a bit at stuff anyway can't hurt (too much) I hope.
16:51 imirkin_: pmoreau: can i see the code that generates this code?
16:51 imirkin_: pmoreau: i.e. where do you emit the cvt?
16:51 pmoreau: Sure, one second
16:51 imirkin_: coz i don't understand what you're doing
16:52 imirkin_: 01211c04 1c000000 cvt u32 $r4 u32 $r0
16:52 imirkin_: wtf is that for?
16:52 imirkin_: i'm betting you're not setting the sType on the cvt
16:53 imirkin_: or it's otherwise becoming U64 instead of U32
16:57 pmoreau: imirkin_: https://phabricator.pmoreau.org/diffusion/MESA/browse/spirv_1.0/src/gallium/drivers/nouveau/codegen/nv50_ir_from_spirv.cpp;36c813be73a30964a7c22a35ecf1729620bc084c$2046
16:58 pmoreau: I don't seem to set sType, indeed
16:58 imirkin_: use mkCvt
17:01 imirkin_: bbl
17:23 pmoreau: imirkin: Works better :-)
17:25 pmoreau: Just missing that the convert doesn't get updated if the value is downgraded from 64 to 32.
17:26 pmoreau: I have `mad u64 %r0d %r1d %r2d; cvt u32 %r4 u64 %r0d`, which ends up as `mad u32 %r0 %r1 %r2; u32 %r4 u64 %r0d`
17:30 imirkin: pmoreau: check the split64BitOp thing
17:30 pmoreau: Ah, right
18:06 pmoreau: It seems trickier to solve than what I thought, as the values are cloned in the split64, I can't detect that they changed when visiting the following instructions using those splitted values. I'll try again tomorrow.
18:07 imirkin: split just forces regs to be allocated together...
18:12 pmoreau: That's not what I meant.
18:13 pmoreau: But more that CVT (or others) will continue using a 64-bit value, even if in reality it became a 32-bit one (since the upper 32-bit was 0).
18:13 pmoreau: Which makes me realise that I was trying to solve the problem the wrong way
18:14 pmoreau: As I was expecting the src of CVT to have become a 32-bit value, rather than trying to split CVT… --"
18:15 pmoreau: Which doesn't make much since either
18:17 imirkin: i have no idea what you're trying to say...
18:22 pmoreau: A summary would be: everything I tried (and thought about) sucks. I'll have another try after getting some sleep. :-D
18:23 imirkin: a little defeatist =/
18:23 imirkin: anyways, if you can summarize what you're trying to do and the problem you're encountering, i may be able to help
18:23 imirkin: as it is, i can't quite tell what the issue is or what problem you're trying to solve
18:24 pmoreau: Well, it's 03:23 here, so I'm falling asleep ;-)
18:24 pmoreau: But right, I'll try to write something that makes sense
18:25 imirkin: not necessarily right now
18:25 imirkin: sleep on it :)
18:32 pmoreau: So: Initialy, the code is handling 64 bit values, which get converted to 32 bit (and then back to 64…). However, after some optimisation passes, the initial values become 32-bit ones.
18:32 pmoreau: But, the convert operations remain the same, and try to convert a 64-bit value (which in reality is now 32) to a 32-bit value.
18:32 imirkin: opt happens before splitting
18:33 pmoreau: The trace is here https://phabricator.pmoreau.org/P95
18:33 imirkin: the scenario you're describing shouldn't be possible :)
18:33 imirkin: so either i'm not undrestanding, or something silly is happening
18:37 pmoreau: No, it's me being sleepy. The values seem still fine, only the first convert which is emitted wrongly: "01a11c04 1c000000 cvt u32 $r4 ??? $r0 [unknown: 01800000 00000000] [unknown operand]"
18:38 drathir: anyone familiar with GF106GLM and high power consumption at nvidia drivrers?
19:49 Jayhost: imirkin How to map. Read https://www.opengl.org/registry/specs/ARB/tessellation_shader.txt first?
19:50 imirkin: mmmm.... probably a bit too broad
19:50 imirkin: and too detailed
19:51 imirkin: tess shaders can have outputs, and all invocations are run in parallel. an invocation can write its outputs, but it can also read any other invocation's outputs.
19:51 imirkin: tess control shaders, that is
20:06 imirkin: with fermi/kepler, you used to be able to use ALD(.O), but now you have to read some weirdo special registers, and use ISBERD(.O) somehow.
20:07 Jayhost: Should I use certain demmt options. Where to read about ALD(.0) and the respective nouveau code?
20:08 imirkin: well, for example... (give me a few)
20:09 imirkin: http://hastebin.com/eleriloyij.sm
20:09 imirkin: this is from the output of demmt -l gm107-tess-sanity.mmt.xz
20:09 imirkin: note how the TCP and TEP (tess control program and tess evaluation program)
20:10 imirkin: both do funny business wrt ld.o and isberd
20:10 imirkin: that funny business needs to be worked out
20:10 imirkin: you can also feed this stuff through nvdisasm, so e.g.
20:11 imirkin: http://hastebin.com/nodowuxucu.cs
20:11 imirkin: just to pick a random chunk (it has to be in groups of 4 starting with sched...)
20:12 imirkin: [did i mention this wasn't going to be trivial?]
20:14 Jayhost: ha yes
20:16 imirkin: btw, when you see bs instructions like 00000100: e7a007f0 087fc000 $p0 fadd32i cc $r240 abs $r7 neg 0xfc000e7a
20:17 imirkin: that's just a sched
20:17 imirkin: every 4th op has to be a sched
20:17 imirkin: but we don't properly detect that sometimes
20:19 imirkin: al2p used to have to only be used for indirect input/output accesses, it appears to be getting used all the time now
20:42 Jayhost: I see
20:45 Jayhost: I think I'm gonna have to read up quite a bit
20:48 imirkin: yeah.... *basically* you just have to trace stuff and figure out how they use those crazy new ops/values
20:48 imirkin: and by trace i mean read the shader and convert it into a C-ish program
20:49 imirkin: and then try to map that into the original shader
20:49 imirkin: (the glsl one)
20:51 Jayhost: That doesn't sound too bad
20:56 Jayhost: I probably should try not to understand so much in order to get results.
20:57 imirkin: good idea.
20:59 imirkin: understanding is overrated
21:03 mooch: ugh, i can't understand the interaction between pfifo and the user area on nv4
21:33 Freeheart: I would like to donate money and/or hardware to the Nouveau Project in hopes of resolving problems that I'm having with every major distro.
21:33 Freeheart: Is there currently a bounty program set up for such things?
21:35 imirkin: not really
21:35 imirkin: but if you say what your problem is, perhaps we can help
21:36 Freeheart: Nice reframe. :)
21:37 Freeheart: I currently have a workstation with two nvidia cards, GeForce GTX 750 and GeForce GTX 960. No other draphics devices.
21:37 imirkin: ah yeah, that story isn't going to end well
21:38 Freeheart: I generally use the GeForce GTX 960 to power a Windows 10 VM, and use the pci-stub module to stop nouveau or nvidia from grabbing my 960 at boot.
21:39 imirkin: you should also make sure that it's your secondary gpu then
21:39 imirkin: i.e. not the one whose option rom is executed
21:39 imirkin: on bare metal boot
21:39 Freeheart: Oh, yeah, I know. :)
21:40 Freeheart: Mobo defaults to the 750 for the Linux host. :)
21:40 Freeheart: Boots fne.
21:40 imirkin: so the problem is...
21:40 Freeheart: Actually... I *always* use the 750 for booting Linux, and I never boot a non-Linux guest. :P
21:41 Freeheart: When I perform a fresh install of most major distros, I get hard locks using Nouveau and my current hardware configuration.
21:42 imirkin: you said linux booted fine?
21:43 Freeheart: I'm being very specific here, to make sure that there's no confusion... It might be pedantic, but I have not booted anything *other* than Linux on my host machine.
21:44 Freeheart: My Windows 10 thingy is a VM. The host machine always runs the Linux kernel, in some form.
21:45 imirkin: right
21:45 imirkin: so i'm still unclear as to when the issue happens
21:46 Freeheart: Ah, okay. Let me ponder for a second...
21:47 Freeheart: I am currently using my main workstation to have this conversation. Right now, it's capable of launching a usable X session.
21:48 imirkin: sounds like a good thing to me
21:50 Freeheart: If I were to cat /dev/null to /dev/sda, /dev/vda... my system wouldn't boot. :) And the hardware that I'm currently using would need an OS install in order to have this conversation. :)
21:51 imirkin: ok
21:51 Freeheart: Using my current hardware setup, a fresh install using nouveau causes hard locks that require me to reset my tower.
21:52 imirkin: what's different between a fresh install and the current install?
21:52 Freeheart: Occasionally, I can move past the lightdm, kde, or gdm greeters, but usually, I get a freeze.
21:52 Freeheart: A fresh instally usually doesn't depend on the Nidia blob.
21:52 Freeheart: nvidia*
21:54 Freeheart: I have found *zero* setups using nouveau that last long enough to launch an X session, let alone a web browser.
21:54 Freeheart: With my specific setup.
21:55 imirkin: does your current setup use blob?
21:57 Freeheart: Yes. I am currently using the blob from the 361.28 installer, on Debian testing.
21:58 imirkin: ah. might want to lead with that info next time :)
21:58 imirkin: what kernel does debian testing use?
21:59 Freeheart: Sorry, I'm just frustrated. Thanks for helping me prioritize.
21:59 Freeheart: As of this moment... Debian 4.3.5-1 (2016-02-06) x86_64 GNU/Linux
22:00 imirkin: hmmm... that should be recent enough for nouveau to work with the GM107...
22:01 imirkin: well, if you want debugging assistance, you'll need to provide logs - specifically dmesg and xorg logs at the time that things go sour - you can probably still ssh into that system
22:01 imirkin: i'm heading to sleep though... good luck
22:01 Freeheart: The best experience I've ever had using this hardware setup was Korora 22.
22:02 imirkin: you can turn off nouveau's accel by booting with nouveau.noaccel=1
22:02 imirkin: which will keep modesetting but disable all gpu-based functionality
22:02 Freeheart: Where would I add that option? Is that a boot parameter?
22:02 imirkin: yes.
22:03 imirkin: well, noaccel is a module parameter
22:03 imirkin: you could stick nouveau.noaccel=1 into the kernel cmdline
22:03 imirkin: or add noaccel=1 when loading the nouveau module.
22:03 Freeheart: Awesome, I'll test. Thanks for your help.
22:03 imirkin: good luck!