00:02guest42: maby all i can run is mesa 11 because it just doesnt update to 12
00:03guest42: 12.1~git1608261930.0035f7~gd~x is like 5 hours old
00:24DexterF: can I have vdpau with nouveau? do I need a specific driver package in say ubuntu?
00:30DexterF: nvm, faq got it
01:29f380cedric: Hi, I have a question, GTX 1070 is supported by nouveau or I need to use proprietary 367 driver?
01:34f380cedric: forget, I found on nouveau site :p
03:31BoRiS: Hi everyone!
08:13karolherbst: okay, again
08:13karolherbst: hakzsam: I will just do a very quick test on reator (5 minx max)
08:16karolherbst: seems like a maxwell2 pmu has the same imem size as my kepler
08:19karolherbst: RSpliet: it seems like 0x10a1c0 does something else on maxwell2
08:25karolherbst: I just got the maxwell2 pmu image though the imem window :O RSpliet, thanks for the hint
08:25karolherbst: though that doesn't help at all, because we miss everything else
08:45Yoshimo: every little additional detail you know is good karol
08:56hakzsam: karolherbst, np
08:56hakzsam: wale up time
08:56pmoreau: karolherbst: PMU image == PMU firmware? If so, can’t you use it to change the fans’ speed?
08:57karolherbst: pmoreau: we need more than that
08:57karolherbst: and with image I meant the code space
08:57pmoreau: But that’s some progress at least
08:57karolherbst: for the acr we need the bl and ucode_load
08:58karolherbst: ohh wait, that we can reuse from the other things
08:58karolherbst: but we need the pmu bl, data, inst and sig
08:58karolherbst: data and inst we have now
08:58karolherbst: now idea if we can use it though this way
09:06hakzsam: karolherbst, let me know when reator is available
09:07karolherbst: hakzsam: ohh right, I am done already
09:07kloofy: pmoreau: did you look at this stupid pseudo i posted? seems you are lately active, but i gotta go, we talked that i don't very much care either, more iportant things to do, but
09:07karolherbst: pmoreau: do you know what would be cool? A falcon emulator
09:07kloofy: ? pmoreau: it is almost correct in the flow
09:08karolherbst: pmoreau: which we could run on either mocked hw mmio regs or the real deal to RE those pmu images without the need of disassembling
09:09karolherbst: or putting it on real hardware
09:09kloofy: pmoreau: let's just say someone who wants the perf may plug it it in with only slight hairy work at isa level
09:13pmoreau: kloofy: I had a quick look, but honestly did not understand it. So, if you have two warps running through the same conditional, you would like to group threads going through the `if` in one warp, and the `else` threads in another wrap, and have them run in parallel rather than sequential ?
09:14pmoreau: karolherbst: The number of possible cool things is not that limited, but… the available time is sadly :-/
09:14kloofy: pmoreau: well actually, first thanks for responding, it is done via masks, which i did not mark explicitly
09:15kloofy: pmoreau: so the in case of fast instruction those are uniform 100 and 100 for both
09:16kloofy: but in case of instruction that is deeply pipelined, nvidia even has a page for them, i.e those would run with fewer threads yeah
09:16kloofy: which means that else clause is sent back to the circuit to do other things
09:17hakzsam: I hope to find the F1 2015 hang today because it's really annoying to debug
09:19kloofy: there are couple of bugs, i may do the more precise version with more descriptions including the nouveau based cctl and radeon and nv50 based ring buffer pseudo code
09:20kloofy: pmoreau: namely it should count the loops index when incrementing to next instruction
09:20kloofy: i forgat to mark correct arithmetic there
09:23karolherbst: pmoreau: but I am sure we can simply take the acr files from the released stuff
09:23karolherbst: they are also the same between chipsets
09:24kloofy: actually i did in the past some thesis reading but i lost the thesis, the branches are done in parallel in hw, but with fewer threads, so that the instruction that is in question which threads were lowered performs longer
09:25kloofy: if done against the instruction which normally is has enough units or can take on all the threads
09:26kloofy: i had one german pdf, which said that threads masked off will do nop and skip to the else so it's done in parallel, the intention is not to add those threads when they would do nothing in reare cases
09:30kloofy: so for instance non-cache memory operation would have most threads masked with exec mask, while cached memory read will have few threads marked, and bunch of other instruction little ofer a tosin of them will have half of the threads masked
09:32kloofy: and if you can bit optimize my code then it should raise the perf in quite large degree once you do the code inside the driver
09:35kloofy: the mask i can't remember should look, is the exec there, it's read from the ringbuffer from tiling regs, and right after it was read the tiling regs will be readjusted
09:36kloofy: on radeon that is memory or constant engine and their polling which can be used for that and it either needs coherent cache between waves or shader must invalidate
09:40kloofy: but that is radeon code, fermi and kepler is simpler, this can ask physical bank stuff with cctl instead
09:41kloofy: i last time this was the patent number 4 i posted
09:41kloofy: the idea is that cpu does not need to reorder instructions this way
09:42kloofy: cause there will be mask held in tiling regs on the circuit per instruction in the mmio regs, which karolherbst said it's an arbitrary reg on the circuit
09:44kloofy: you can look at this stuff, as the instruction address was virtually tagged and physically indexed
09:45kloofy: so basically 40bit of program counter is virtual tag that is contiguous, but physical index is non-contiguous
09:47kloofy: in overly simplfied explanation, it's like register reuse implementation for the tiling regs of memory controller
09:49kloofy: so you write into tiling , regs upfront during compilation
09:49kloofy: in the shader you send the me engine a signal to read from it via cached memory, and then reuse it to add correct tiling info, so that tiles would not be random
09:52kloofy: but on kepler and fermi, there are special instruction in the shader to ask and mark the physical taggs of a virtual address
09:52kloofy: this is very elegant stuff, it also can determine wether the address is in cache
09:53kloofy: so there you know, that ooops address is not in cache, mask of nearly all of the threads, cause this very high latency memory operation
09:53kloofy: but on readeon and nv50 that last thing can be done too
09:54kloofy: but in slightly the way which would work out nearly the same but seems to the user more complex to figure out
09:56kloofy: and if you look at the patents i pasted from nvidia 4 of them, they are all relevant to this implementation
10:10Tom^: the wall of text
10:22kloofy: pmoreau: i as always present i have been read though, i am tired a bit of the reading i need to do practical stuff too occationally, but i lost the thread where it said about uncached memory it was thesis again, that it really needs only 4 threads active in a warp to utilize it's maximum potential
10:22kloofy: i/what i
10:26kloofy: but in comparison with sched opcodes there are few hurdles
10:27kloofy: as we do not know what is the delay in circuit caused of sched opcodes, maybe there is literally none, we'd want to keep the handler which will be executed per every instruction as thin as possible
10:28kloofy: and on sm3 i yet haven't decided how i will workaraound the possible in spec branching limit, cause i used 4branches there too, if user is stupid to use 20nested branches we are not in spec anymore
10:28kloofy: err 24
10:31kloofy: but the advantage is that we can test during runtime and adjust the mask
11:09night199uk: anyone can help with nvidia pitch/gobs?
11:11night199uk: esp. i’m looking at pdisp reg 0x86c / 0x46c
12:01karolherbst: mhh, I have found a game where I usually get a lot of stuttering, but OpenGL renders at 6ßfps constantly
12:12karolherbst: nice, found another texture/ram bug
12:13hakzsam: which game?
12:13hakzsam: with mesa master?
12:13karolherbst: 68MB trace :)
12:13karolherbst: a little older than this
12:14hakzsam: I did fix something texture related few days ago
12:14hakzsam: yeah, you need to update
12:16hakzsam: and please upload the trace somewhere
12:16hakzsam: what's the dmesg error btw?
12:19hakzsam: karolherbst, I booked my flight for XDC yesterday, I will be at mupuf's hotel on tuesday around 11pm
12:19karolherbst: hakzsam: so late :O
12:20karolherbst: no error in dmesg
12:20hakzsam: but it was cheaper :)
12:20hakzsam: what's the issue then?
12:20hakzsam: rendering only?
12:21karolherbst: only in this "area" of the game though
12:22karolherbst: and the game has like 300 calls per frame
12:22hakzsam: shouldn't be hard to debug
12:23hakzsam: F1 2015 has something like 100k calls per frame :)
12:23karolherbst: first I update mesa
12:24siro__: karolherbst: looks like wrong data in compressed textures
12:25hakzsam: karolherbst, yeah, but my think is unrelated I think
12:25karolherbst: I see
12:28karolherbst: hakzsam: yep, still wrong
12:28karolherbst: I will put the trace in my google driver and open a bug
12:30karolherbst: trying llvmpipe first though
12:31karolherbst: yep, no issues
12:34karolherbst: hakzsam: the trace is so small compressed. it even fits on bugzilla :D
12:35karolherbst: and I just removed the screenshot...
12:36hakzsam: I will test on gm107
12:36karolherbst: awesome :)
12:36hakzsam: but I'm fully busy with F1 :)
12:36karolherbst: no worries
12:37karolherbst: maybe I will find the issue or so
12:37karolherbst: shouldbn't be that hard
12:37karolherbst: 239 calls :D
12:37hakzsam: at least it's easy to trim :)
12:37hakzsam: and fast
12:37karolherbst: frame 850 is a good one
12:38hakzsam: the F1 trace has 1.5M calls :/
12:38hakzsam: but I found where it hangs, still need to understand why
12:38karolherbst: okay nice, the issue will be something silly, because the background has no corruptions
12:39hakzsam: you tested with blob as well?
12:39karolherbst: I know that it used to work
12:39karolherbst: with nvidia, didn't test today though
12:40karolherbst: call 240510
12:41karolherbst: GL_RGBA4 textures
12:41karolherbst: 2 of them, both messed up
12:43karolherbst: framebugger is a GL_COLOR_ATTACHMENT with GL_RGBA8 and gets two GL_RGBA4 textures drawn into it
12:43karolherbst: can this cause problems?
12:43karolherbst: the textures are already messed up
12:46karolherbst: glTexImage2D(target = GL_TEXTURE_2D, level = 0, internalformat = GL_RGB5_A1, width = 1320, height = 720, border = 0, format = GL_BGRA, type = GL_UNSIGNED_SHORT_5_5_5_1, pixels = NULL)
12:48karolherbst: wrgon call I guess
12:48karolherbst: glTexImage2D(target = GL_TEXTURE_2D, level = 0, internalformat = GL_RGBA4, width = 1320, height = 720, border = 0, format = GL_BGRA, type = GL_UNSIGNED_SHORT_4_4_4_4, pixels = NULL)
12:48karolherbst: that should be the one
12:50karolherbst: imirkin: any ideas?
13:11hakzsam: karolherbst, not exactly the same issue on gm107, but there is one definitely
13:11karolherbst: hakzsam: it doesn't look always the same
13:11hakzsam: so yeah
13:34kloofy: pmoreau: i add a link where probably the ptx generator generates the sched commands, the assembler in question should be free, but i currenltly can't inspect it
13:36kloofy: so in theory if you know how to mark those delays in ptx, and that is what people should know, since probably it is descibed in ptx spec, the plumbing of those can be added to mesa from this assembler
13:36kloofy: the same thing is known to be available for maxwell too
13:37kloofy: but the other way i described should function too if added, i am quite sure it would
14:06kloofy: https://github.com/NervanaSystems/maxas/wiki/Introduction there the sched codes should be generated automatically when stuff is put to schedblock
14:09kloofy: listen folks, i gonna head off i don't care about who ignores me, it's their own deal, i just want to live so that persons who do not respect any of the humanity standarts can
14:11kloofy: t come to my areas at all, and better not talk to me, and spammer is better then the terrorists like that
14:11kloofy: what is more importand not to talk about me, cheers.
14:58imirkin: karolherbst: hopefully it magically works on nv50 and i can do a retracediff
15:00karolherbst: well, I think I pinpointed the messed up calls already and thought that the rgba4 format might cause issues
15:00imirkin: it's caused issues in the past
15:00imirkin: although iirc i discovered that those issues were actually entirely unrelated to rgba4
15:01imirkin: but i did "fix" those issues for a while by disabling rgba4 support
15:02karolherbst: uhhh, i see
15:02karolherbst: maybe I should bisect and check
15:03imirkin: i'll look later today probably
15:03imirkin: those render bugs tend to be pretty easy to fix
15:03karolherbst: I will see if 10.0 has this issue, I doubt I will go more into the past
15:03imirkin: or at least diagnose
15:04imirkin: not always though
15:05imirkin: if you and i were smart, we'd have pre-built versions of mesa releases lying around for easy referencing
15:05imirkin: too bad we're not smart.
15:09karolherbst: 10.0 doesn't even compile due to the libdrm changes...
15:28karolherbst: imirkin: it works with 11.0
15:28karolherbst: I like regressions :D easy to track down
15:36karolherbst: do you think this is related?
15:36karolherbst: Mesa: User error: GL_INVALID_FRAMEBUFFER_OPERATION in glDrawRangeElements(incomplete framebuffer)
15:36karolherbst: Mesa: User error: GL_INVALID_FRAMEBUFFER_OPERATION in glClear(incomplete framebuffer)
16:00karolherbst: it works between 11.0-branchpoint and 11.0.0
16:00karolherbst: 11.0-branchpoint has the issue, 11.0.0 not
16:00karolherbst: but 11.1 has the issue again
16:58karolherbst: imirkin: it seems like the PageFlip option causes issues for nouveau, turning it off eliminates some rendering issues
17:35karolherbst: imirkin: I guess you was right about removing RGBA4 support, I bisect towards that one
17:36karolherbst: imirkin: but is this patch only applied for 11.0?
17:45hakzsam: karolherbst, have fun with reator
17:45hakzsam: I'm done
17:46hakzsam: F1 still not fixed :/
17:46hakzsam: I know where it hangs but I don"t know what does it happen
17:47karolherbst: currently I am trying to figure out why that rgba4 issue doesn't exist on the 11.0 branch
17:50karolherbst: 0878187488008facccbdae1b0e5258234a2b9dd4 fixed the issue
17:50karolherbst: now checking the master commit
17:51karolherbst: that issue
17:52karolherbst: I remember
18:16imirkin: karolherbst: right, but it was a misdiagnosis ... i fixed the issue for real later
18:17karolherbst: yep, I currently bisecting starting from the disable commit and see where it leads me to
18:20imirkin: ok, well, i'm not against you tracking this stuff down, but chances are i'll have a look in an hour or two
18:20karolherbst: I have to tidy up a bit anyway, so I really don't mind
18:21karolherbst: I am sure it will lead to a "enable rgba4 again" commit or something like that, but maybe not, who knows
18:28karolherbst: imirkin: do you happen to know a nice task somebody could do on a maxwell2 gpu without needing much experience with nouveau?
18:29karolherbst: awesome :)
18:29imirkin: GM20x added a bunch of exts
18:29imirkin: some of which are going to be pretty involved to implement
18:29imirkin: but a bunch should be extremely easy
18:30karolherbst: I search for easy ones
18:30karolherbst: best if there are already piglit tests
18:30imirkin: NV_conservative_raster, NV_fill_rectangle
18:30imirkin: nah, they're new
18:30karolherbst: I see
18:30imirkin: one could also add support for AMD_vertex_shader_layer and AMD_vertex_shader_viewport_index
18:30imirkin: those already have tests
18:30imirkin: i had a patch which made one of them work but not the other
18:30karolherbst: imirkin: do you want to create trello cards for those?
18:30karolherbst: maybe best would be a new category for this
18:31imirkin: opengl features
18:31karolherbst: where we just keep track on those
18:31imirkin: i think that cat exists :)
18:31karolherbst: right, would fit
18:31karolherbst: well I will create them and mark those as easy
18:32imirkin: we both just added them
18:32karolherbst: ohh :O
18:32imirkin: mind if i nuke yours?
18:32karolherbst: nope, go ahead
18:32imirkin: i'm going to add additioanl info too
18:33karolherbst: awesome, thanks
18:33karolherbst: you don't happen to know other issues, which aren't exactly opengl related?
18:34imirkin: karolherbst: easy ones? no
18:34imirkin: one could try to figure out how to operate the video decoding engines
18:35imirkin: however that's a life sucking effort
18:35karolherbst: the only "easy" task I have is to adjust nvkm_clk_read to kepler2+ changes
18:40imirkin: pmoreau: do you still have my patch from when i was trying to implement the GM20x vertex shader layer/viewport index stuff?
18:46imirkin: karolherbst: how's that?
18:46imirkin: karolherbst: i had a partial patch for the first one that didn't work, but it might have been lost in the annals of time. i think pmoreau had it at one point...
18:46imirkin: iirc i didn't push it anywhere
18:47karolherbst: looks very good, thank you
18:48karolherbst: we should always try to create cards for things we know has to be done, just so that somebody who has a lot of spare time knows what he might do to help out
18:48imirkin: yeah, i'm usually decent about that
18:48imirkin: a lot of the stuff is pretty involved though
18:48karolherbst: implement vblanc on the pmu :D
18:49karolherbst: terrible task though
18:49karolherbst: mhh for gf119+
18:53karolherbst: mhh I could try to figure out why setting the liveOnly bit on the tex instructions causes hangs
18:54karolherbst: ohh implementing clock gating on kepler+ should be a good beginners task
18:54karolherbst: no REing needed at all
18:54karolherbst: just coding mainly
18:54karolherbst: maybe a bit of mmiotracing, but that's fine
19:01kloofy: well guys one more thing, this is about vulkan, the precompiled blobs can be generated from vulkan too, so theoretically people could use vulkan too, instead of opengl, but sadly we then need vulkan front-end i.e to get a precompiler ontop of vulkan, we need vulkan support in the state tracker
19:02kloofy: unfortunently for me to make it perform better i should also study it, but i don't have that much time
19:02kloofy: it/the spec, so but life sucks lots of different apis and things change
19:03kloofy: anyhow , so bye.
19:07MarkedOne: Hello.. I am forced to use proprietary NVIDIA driver for my GeForce GT 520M.. As you are here experts wchich driver version should I use? https://wiki.debian.org/NvidiaGraphicsDrivers
19:08imirkin: MarkedOne: ask nvidia folk for support on nvidia driver
19:08karolherbst: "forced" is a rather strong word, who forces you?
19:08imirkin: i believe there's even a channel for it, #nvidia
19:09MarkedOne: i would like to use nouveau.. but bumblebee is not working... and karolherbst told me that nouveau driver is working bad with my GPU
19:10MarkedOne: karolherbst: Oh thats you :D
19:11MarkedOne: karolherbst: Nice to see you again :D
19:11karolherbst: well yeah, you should ask within bumblebee, but usually a normal bumblebee package is enough
19:11MarkedOne: I really don't like Nvidia blob :/
19:11karolherbst: I doubt there is one for debian though
19:12karolherbst: well, we are working on that, but we can't say when it will be done, because that part is really tricky
19:12imirkin: MarkedOne: irrespective of how nouveau works for you, or your reasons for using nvidia blob, this isn't the place for nvidia blob support
19:12MarkedOne: imirkin: Yeah sorry...
19:14MarkedOne: karolherbst: So you are working on it? That is wonderful! :) I will definitely wait.
19:15karolherbst: nope, I am not
19:16MarkedOne: karolherbst: You said that :D
19:16karolherbst: I didn'T
19:16imirkin: when he said "we" he meant "group of people that does not include me"
19:16karolherbst: as always
19:18MarkedOne: anyway :D I appreciate your work
19:19MarkedOne: And karolherbst :D I like your definition of "we" :D
19:19karolherbst: it is the usually used one on the internet
19:19karolherbst: "we" fight for human rights ;) you know
19:20MarkedOne: yeah :)
19:20MarkedOne: btw how are you?
19:21karolherbst: well annoyed by silly bug
19:22karolherbst: imirkin: https://github.com/imirkin/mesa/compare/581111c4d67c65305dcae83789ac504deeec9da2...bf6acbb2db4baaf18ae5a139142acf06e84d1b9c
19:22karolherbst: guess which one
19:22MarkedOne: hmm.... the whole world is full of bugs :D
19:22karolherbst: like my sleeping room
19:22karolherbst: bedroom you call that
19:23imirkin: karolherbst: looks like a bug in the game...
19:23karolherbst: it works with llvmpipe and intel
19:23karolherbst: and nvidia
19:23imirkin: 95906: message: major api error 3: GL_INVALID_FRAMEBUFFER_OPERATION in glClear(incomplete framebuffer)
19:23karolherbst: sure, but that message doens't appear when RGBA4 is disabled
19:24imirkin: doesn't make it less of a bug in the game
19:24karolherbst: and why doens't the message appear in those cases?
19:24MarkedOne: Okey guyz.. i am lost... can't get your conversation so i will fade to black :D
19:24MarkedOne: wish you nice day :)
19:25imirkin: interesting though ... it does seem like it ought to work
19:26imirkin: oh right
19:26imirkin: yes. bug in the game.
19:26imirkin: C4(A, B4G4R4A4_UNORM, NONE, B, G, R, A, UNORM, A4B4G4R4, T),
19:26imirkin: we don't support rendering to BGRA4
19:26imirkin: so it creates a BGRA4 texture, which we support
19:26imirkin: and then tries to render to it without first checking if the fb is complete
19:26imirkin: which is illegal
19:27imirkin: when we totally disable the BGRA4 support in nouveau, the st falls back to creating a BGRA8 texture, which in turn *is* renderable, hence no issue
19:28karolherbst: mind putting a text together I can send to the publisher/devs?
19:28karolherbst: but then I am wondering why this issue doesn't happen with other drivers
19:28imirkin: "you have to check if fb is complete before assuming you can render to any ol' format"
19:32imirkin: perhaps other GPUs don't have this asymmetry issue for this particular format, or perhaps other drivers are "nice" and flip things around. fwiw i was unable to get blob to even use the BGRA4 format in the first place, perhaps it doesn't enable it for precisely this reason
19:32karolherbst: I see
19:32karolherbst: maybe you need to use it right from the start without creating any doubts for the driver that it would be save to use it
19:32karolherbst: anyway, I am sure the devs won't fix that issue, cause they are rather small + they most likely won't bother :/
19:32karolherbst: maybe they will
19:32karolherbst: they are located in toronto though
19:35imirkin: karolherbst: i've noted my findings in your bug
19:41imirkin: karolherbst: should they come back to you with "no, you're wrong, here's the spec", i'd be happy to revisit it. however i'm moderately sure i'm right.
19:41karolherbst: imirkin: wanna on CC?
19:41imirkin: not particularly
19:44karolherbst: imirkin: but I think we would have to workaround this in some way :/ or not?
19:45imirkin: i'm not particularly inclined to do that
19:45imirkin: you can just nuke BGRA4 support locally
19:45karolherbst: hmpf :/
19:46karolherbst: and no other drive has BGRA4 texture support?
19:46karolherbst: well where that game would run on
19:46karolherbst: not even some radeon gpus?
19:46imirkin: alternatively we could have logic in the st for when someone tries to render to a texture AND that texture hasn't been allocated yet AND that format is unrenderable, to upgrade it to a renderable format
19:46imirkin: more likely they can render to BGRA4 :)
19:47karolherbst: I see
19:47karolherbst: well, that would be a solution
19:47karolherbst: and with a printed warning that would be also fine I guess
19:47karolherbst: I suppose that is also what nvidia does
19:48imirkin: no, nvidia just never makes use of the BGRA4 texture support
19:48imirkin: at least i couldn't get it to spit it out
19:48karolherbst: is there a valid reason to support BGRA4 in such a case at all?
19:49imirkin: if an application uploads BGRA4 textures and wants to texture from them
19:49imirkin: also apparently st/nine relies on it
19:49imirkin: although arguably they should provide fallback logic
19:52karolherbst: I see
21:13pmoreau: imirkin: Could be that I still have it lying somewhere on that computer
21:14imirkin: pmoreau: please have a look if it's not too hard
21:14pmoreau: Should be easy
21:20pmoreau: I saw there were some new cards on the Trello
21:20imirkin: for someone who cares about gm200, yes
21:21karolherbst: well, it would be nice to have such cards for older chipsets too
21:21karolherbst: I was just thinking having more "easy" tasks there would really help
21:24pmoreau: imirkin: I still do have some modifications :-)
21:38pmoreau: imirkin: There you go: https://phabricator.pmoreau.org/P103
21:39imirkin: right thanks
21:40imirkin: uploaded it into the trello thing
22:14pmoreau: How is FILE_MEMORY_BUFFER different from FILE_MEMORY_GLOBAL? I wanted to have a quick try at plugging in `atomic_add()` support, it looks like I give in the wrong file type for the pointer.
22:15imirkin: FILE_MEMORY_BUFFER takes a fileIndex
22:15imirkin: and loads a base address from a constbuf
22:15imirkin: and does limit checks
22:15imirkin: FILE_MEMORY_GLOBAL is totally unchecked, feed it whatever pointer and have fun.
22:17pmoreau: That sounds more involved than what I was hopping for. Will have another look tomorrow. :-)
23:49imirkin: this is a tall order, but i don't suppose anyone in here has ever tested the current nouveau_vieux driver against a nv25/nv28 card?
23:49imirkin: [or even nv20]