00:19AndrewR: imirkin, https://bugs.winehq.org/show_bug.cgi?id=41394
00:27imirkin: AndrewR: cool. let me know if they put the blame back on me.
00:28AndrewR: imirkin, OK (going to bed right now)
03:04sigod: Hi, I'm using nouveau, xfce, compton and my audio is out of sync on most hd movies. Where should I look to troubleshoot?
03:10imirkin: what video player are you using?
03:10sigod: vlc and smplayer, same result on both
03:11sigod: usually by 200ms ish
03:11imirkin: does mplayer print messages like "your computer is too slow"?
03:11sigod: ill have a look
03:12imirkin: specifically 'Your system is too SLOW to play this!' surrounded by a bunch of *'s
03:20loa: sigod, compton is garbage.
03:24imirkin: sigod_: what gpu do you have, are you using vdpau?
03:25sigod: gtx 660 no im not using vdpau
03:25sigod: my X just froze playing a movie and i had to restart
03:25imirkin: hm odd
03:26imirkin: fwiw i generally tend to use 'mplayer', and it works fine. although afaik smplayer is just mplayer + cheesy gui
03:26sigod: also there is a delay on both my motherboard audio and external dac
03:26imirkin: does mplayer *think* it's in sync? it normally prints a A-V number
03:26imirkin: e.g. "A:1199.0 V:1199.0 A-V: 0.000"
03:28sigod: ill show you on pastebin
03:31imirkin: oh hm. it doesn't have the same output as mplayer
03:31imirkin: mind using mplayer directly/
03:38sigod: hmm it says A0 OSS can't open audio device first no such file or directory then it uses alsa
03:39sigod: 0.000 ct
03:39imirkin: ok, so mplayer thinks it's in sync
03:40imirkin: fwiw you can adjust the sync with - and +
03:40sigod: yea i know thanks
04:02karolherbst: you could try another video file
04:03karolherbst: ohh you alread said "most", odd
04:08sigod: it even does it on normal avi's
04:10imirkin: i don't suppose you have a .alsarc which adds a 200ms delay :)
04:12sigod: direct to hardware
04:13sigod: pcm.!default.type plug; pcm.default.slave.pcm.type hw; pcm.default.slave.pcm.card 0;
04:15imirkin: right - i don't even know how you'd do that. and if you did, you'd know about it.
04:15sigod: im all about the correct sample rate
04:15sigod: i have an external dac
04:16sigod: but i use it for my internal sound too
04:16karolherbst: can you try with on board audio device only?
04:16sigod: same result
04:16karolherbst: could be simply alsa messing up
04:16karolherbst: i see
04:17sigod: everything is good no tearing just the audio is slightly out
04:18sigod: nice to have things right
04:18karolherbst: well if you dont have any input lag as well, it seems to be an alsa issue then
04:19sigod: all my alsa settings are stock
04:19sigod: apart from asoundrc
04:21karolherbst: mhh cant help now anyway, have to board the plane
07:13zeq: Congratulations on XDC for all those involved. I just finished watching all the presentations, would have liked to have been there, but getting to youtube is much easier than getting to Finland! ;-)
07:27zeq: I've had to give up getting nouveau working on my G80 and NV35, rather unfortunate cards to have! However, I would really like to get the Fermi in my laptop into a useful state. Last time I was here I said I'd do what I could to help, I've just been sidetracked with other projects. You may, or may not recall, *all* my Fermi needs is to have the memory reclocked, it has no memory voltage map table. My idea was to create a fake voltage
07:27zeq: table from the boot parameters, I did try hacking this in myself, but at least last time I tried I wasn't successful. Is there any chance of someone who knows what they're doing implementing it? Or a better solution? Otherwise I will take another stab at it [but like I said, I don't really know what I'm doing!] .
07:36zeq: Oh, one other thing, my laptop does have a MUX, I tried playing with vgaswitcheroo, and also playing with disabling Optimus in the UEFI setup. It's quite interesting. Having Optimus disabled results in the card *not* being initialised into text mode, and also incorrect LCD timings (half-height), which causes nouveau to just output garbage, then fade to white. The Linux NVIDIA driver doesn't do much better, it complains about the lack
07:36zeq: of the text mode, then fails to light up the screen/crashes the system. The Windows7 NVIDIA does work okay.
07:36zeq: vgaswitcheroo is available, switching to the DIS GPU seems to actually switch, but nouveau fails to initialise. I've not managed to get a log from this as yet. Is this expected to work?
07:42karolherbst: zeq: if you want to help with fermi memory reclocking you should ask rspliet
07:44karolherbst: zeq: another thing: you somehow want to find out first, what nvidia does on your card or what is affected by specific bits in the vbios
07:45zeq: karolherbst: thanks, yes. just watched your talk on Power Management. Looks like the dynamic reclocking is working well! :-)
07:46zeq: karolherbst: I tried that previously, it seemed the NVIDIA driver didn't change the memory voltage at all, as I recall.
07:46karolherbst: well yeah, but not production ready
07:46karolherbst: a lot of things have to be done first and then we can only start with very conservative algorithms
07:47karolherbst: for the demo i had an optimistic one
07:47karolherbst: yeah, that happens sometimes,l
07:47zeq: I honestly think my GPU is a little weird, just having the one memory voltage
07:48karolherbst: normal on laptops
07:48zeq: ah ok
07:48karolherbst: i have gddr5 memory but also less voltage control on it
07:48karolherbst: desktops usually have 2 GPIOs for this, I have 1
07:49karolherbst: i assume yours has DDR3?
07:50zeq: Does the reclocking algorithm just use the GPU load to determine the need to reclock? Could it take input from the load from processes that have the DRM node open so it could predict when it might need to ramp up?
07:51zeq: 1024 MiB GDDR5
07:52zeq: it's actually quite decent memory. In Windows I can clock it right up to the max frequency.
07:52karolherbst: yeah, there are counters for that on the gpu
07:53karolherbst: pretty trivial to use
07:53zeq: which is all the more ironic since it runs at 135MHz in Linux! :
07:53karolherbst: lowest clocks, yeah
07:53zeq: not useable, as I said :)
07:53karolherbst: well I kind of thought that every GDDR5 based card has at least one memory voltage gpio
07:54zeq: The IVB HD4000 GT2 runs circles around it!
07:54zeq: karolherbst: maybe mine is weird then, or I'm just wrong
07:54karolherbst: might wanna paste your gpio table on a site?
07:54zeq: how do I dump it?
07:55karolherbst: in debugfs
07:55karolherbst: and then parse it with nvbios
07:55zeq: I *think* I did prevously send it to the dump email address
07:56karolherbst: yeah, well, i am in the train currently and my laptops battery is pretty much garbage
07:56karolherbst: just got back from helsinki
07:56zeq: did you have a good time?
07:56karolherbst: we sure had
07:57karolherbst: the beer was just frigging expensive :/
07:57zeq: I have it parsed
07:57zeq: where shall I paste it?
07:58karolherbst: any random site, you could use gist or pastebin or whatever
07:58zeq: IUNK21 table record longer than expected [5 > 3]
07:59zeq: so there is a MEM_VREF
07:59Tomin: karolherbst: that's just the government trying to prevent us Finns from drinking too much. Now we (well not me, but some other :D) just buy it from Estonia instead
07:59karolherbst: yeah, I know.
08:00zeq: karolherbst: I'd heard beer is very expensive there... that's why I've not been! ;-)
08:00karolherbst: i live in hamburg, so the difference is quite huge
08:00karolherbst: usually i pay like 3€ or so
08:01karolherbst: zeq: yeah MEM_VREF is the one I also have
08:07zeq: karolherbst: I'm going to go make a coffee. Will be back in a few minutes, let me know if there's anything else I can do... Do you have any idea about MUX/vgaswitcheroo issues?
08:07karolherbst: nope, works for me. what laptop do you have?
08:07siro__: do you use PWM on that single pin to control voltage, or are there just two voltage levels ?
08:07karolherbst: just 2
08:08karolherbst: on desktop GPUs you have a second one. makes 4 levels then i think
08:08karolherbst: maybe just 3, didnt looked into it that much
08:08karolherbst: they might have changed that on pascal though
08:09siro__: do you need to wait some time for the new voltage to settle before ramping up frequency ?
08:11karolherbst: not really afaik
08:11karolherbst: reclocking is pretty fast in general
08:12karolherbst: a full reclock is something around 2ms
08:12karolherbst: with all the cpu waits and all that crap
08:18karolherbst: anyway, now we have to do some thermal and power control
08:24zeq: I thought RSpliet's GPU preemtion talk was interesting. It did leave me wondering though, what impact it would have on SCHED_OTHER. With my IVB, long running CL kernels make the desktop stall, I'm sure this would apply to nouveau too, even if the overhead is more significant on unpredictable workloads I do wonder if it wouldn't be worthwhile for interactive "mixed CL/desktop" workloads. Unless I'm completely off-base.
09:20pmoreau: zeq: Pascal cards have finer-grained preemption, which allows stepping through a kernel on the same card as the desktop is running, without needing a second card. http://www.anandtech.com/show/10325/the-nvidia-geforce-gtx-1080-and-1070-founders-edition-review/10
09:20pmoreau: But Pascal support might take some time…
10:36pq: RSpliet, I bet we could measure the compositor rendering work time and just add some margin to be on the safe side almost always. But even with just a fixed point in the scanout cycle, being able to interrupt any other GPU job would be crucial to not miss vblanks, as other jobs could easily take more than a whole vblank period.
10:37pq: err, a whole refresh cycle, I mean
14:28avph: Hi, I'm wondering how generic/reusable the code is between nvidia gpu models to modeset the display.
14:29avph: e.g. are the regs that need to be set for lets say a VGA display the same on kelper as on fermi?
14:29mwk: whee, first NV3 hw bug found by hwtest
14:29imirkin_: generally, no.
14:30imirkin_: nvd9 is more similar to kepler, but the rest of the fermi series isn't
14:30imirkin_: but there are some similarities
14:30mwk: if PATTERN_BITMAP is submitted and causes a subchannel switch, the previous object's mono format is used instead of the PATTERN's one :)
14:32avph: imirkin_: ok thanks, I'll try to look at that code a bit to see the differences
14:33imirkin_: avph: https://github.com/skeggsb/nouveau/tree/master/drm/nouveau/nvkm/engine/disp
14:38avph: imirkin_: thanks, looks quite different from intel modeset stuff at first sight :D
14:55tobijk: imirkin_: instructions like mul do have a constrained to only take imms as second src? but any reg for the first src is ok, so shader inputs would be ok as well?
14:55karolherbst: tobijk: check envyas
14:56imirkin_: tobijk: shader inputs aren't registers. you need special ops to take in shader inputs.
14:56imirkin_: tobijk: however nv50 has special forms to let you do that
14:56imirkin_: but not fermi
14:56tobijk: imirkin_: so switch srcs and i'm fine? mul f32 %r365 0.001500 c0[0x50] (0)
14:57imirkin_: you can't emit that
14:57imirkin_: const/imm can only go into the second source
14:57tobijk: yep, sure just wanted to know if i can emit c0[0x50] as first src
14:59imirkin_: not on fermi
14:59imirkin_: and not on tesla either iirc
15:02tobijk: woul have been too easy i guess :-)
16:31imirkin_: avph: what are you trying to achieve btw?
16:42avph: imirkin_: see if I can modeset nvidia hardware in coreboot, this is achieved on most intel hardware
16:42imirkin_: avph: oh, someone was working on a UEFI thingie
16:43karolherbst: imirkin_: but wasn't this about flashing a free uefi thing into the vbios?
16:43imirkin_: night99uk or something? doesn't seem to be here right now, or i'm misremembering the handle
16:44imirkin_: same diff - the modesetting code would be the same
16:44karolherbst: I see
16:44karolherbst: yeah it was night199uk
16:44karolherbst: he is online, but not inside that channel though
16:45imirkin_: avph: you can reuse all that code directly btw. you could just take all of nvkm/* and cut out the pieces you don't want and stick them into coreboot
16:45tobijk: karolherbst: can you give this commit a go with shader-db and check the results? https://git.thm.de/tjkl80/mesa/commit/558eaa4377e3aa87a7596db9c9b02ac560a012b2
16:45tobijk: my shader-db is quite small :/
16:45imirkin_: avph: can probably leave out the gr-related accel bits :)
16:45avph: imirkin_: that would be really cool, indeed only framebuffer is need
16:46karolherbst: tobijk: k
16:46tobijk: karolherbst: thx :)
16:46imirkin_: avph: nvkm is generally speaking not particularly linux-dependent
16:46imirkin_: you'll have to write a few shims here and there, but it shouldn't be too bad
16:47imirkin_: then have a look at nv50_display.c for how to drive the damn thing - that file is quite linux-specific
16:47imirkin_: tobijk: that's obviously very hacky... you'll need to pipe it through a little better, via insnCanLoad and whatnot
16:49karolherbst: tobijk: same works for a bunch of instructions, too
16:50karolherbst: you shouldn't have to check for add or mul at all
16:50karolherbst: just optimize the split to mov des 0
16:50avph: imirkin_: ok thanks a lot, that will certainly get me started :D
16:50karolherbst: and then it gets const folded away
16:51imirkin_: avph: the logic required to support pre-nv50 is, sadly, a little different, and not inside nvkm. so i wouldn't worry too much about those yet.
16:51karolherbst: tobijk: and remove that silly assert, we assume compilers are sane usually
16:52tobijk: karolherbst: yeah thats a leftover :)
16:53karolherbst: yeah, but you still should remove the code related to the uses of the split
16:53karolherbst: just optimize split constant into movs
16:53karolherbst: that's all
16:54tobijk: yeah that'd be the next thing to do
16:54karolherbst: if you mean by "next" write a second patch, then no
16:54karolherbst: and I am sure you don't even have to check for the dest type
16:55karolherbst: because if you split a u64 value, you get two u32 movs anyway
16:55tobijk: just made sure there to not break something :) removing checks is always easy
16:56karolherbst: well, you have to rewrite the entire thing anyway now
16:59tobijk: well i keep this one for now, not sure if we miss movs somewhere else
17:00karolherbst: well keep it if you want, I say it is overcomplicated and too specific to be actually overall usefull
17:00karolherbst: for this, the definitions of the split do not matter at all
17:02karolherbst: if you don't want to break something, then that means you don't find shader you actually break, which means you don't know for sure if you break it or not, so making a more general implementations is even more safe, because you will have a higher chance of finding the breakage
17:11tobijk: karolherbst: actually we can make that pass more general if possible, but just folding split wont make it as well, as it looks like the movs originate from other sources as well
17:12karolherbst: nope, because you split the immediate on the cpu
17:12karolherbst: what you basically want to do is, to find splits which source is an immediate
17:12karolherbst: or a mov imm or something like that
17:12karolherbst: and then you can just do the split according to the type and the value of the immediate
17:13karolherbst: and have two muls instead of the split
17:13karolherbst: and other passes can constant fold those movs
17:13tobijk: karolherbst: no doubt of that, but we have movs originating from non splits as well
17:15karolherbst: always prefer two generic opts over one specific one
17:15karolherbst: if there is something unoptimized regarding movs, do another opt, that simple
17:16tobijk: thats what i meant with keeping and simplifying this pass and writing the split pass
17:18karolherbst: well, in my opinion you can't simplify it, because the split pass will be too different in the end
17:19tobijk: but i dont care for splits here really, just for movs
17:20karolherbst: but afaik this is done already
17:20karolherbst: muls with immediates as sources should be folded in already
17:20tobijk: karolherbst: yeah should
17:21karolherbst: I know for sure there is, maybe it doesn't handle movs yet, but it still should
17:22tobijk: karolherbst: most movs are folded in, but it misses some, which i fold here
17:22karolherbst: I am pretty sure, those happen to appear after the constant fold opt
17:23karolherbst: tobijk: try with that patch: https://github.com/karolherbst/mesa/commit/e2ae247aa27ddb150ff4ccd1c0f19baa470134ef
17:23karolherbst: this should do the trick
17:23karolherbst: mhh, won't apply for you though
17:23karolherbst: but you get the idea
17:25tobijk: karolherbst: mhm that is pretty bad to run those in a row :O
17:25tobijk: in means for runtime
17:26karolherbst: I know
17:27karolherbst: you should look over the mul constant folding thing
17:27karolherbst: and then try to convince me why it is a good idea to do the same in later passes again
17:28karolherbst: because there is a chance we create a situation again, where this opt applies
17:28karolherbst: allthough I am sure in your example something else should be funky
17:29karolherbst: could you give me an ir dump where you have non opted muls with constants?
17:31tobijk: karolherbst: there are some bl2 shaders
17:32tobijk: i'll try to find them again
17:44hakzsam: karolherbst, fyi, I have just pushed something in mesa which allows to force compiling programs, very useful for shader-db. For example, NV50_PROG_CHIPSET=0xf0 ./run -1 <path> will compile all shaders with the GK110 emitter
17:44karolherbst: yeah I was somehow aware of this
17:44karolherbst: well you posted patches at some point I think
17:45karolherbst: I think mupuf will like that, too
17:45hakzsam: yeah, before XDC
17:45hakzsam: now it's upstream
18:01tobijk: karolherbst: http://hastebin.com/ujokebiyar.http
18:02karolherbst: tobijk: kepler1?
18:03tobijk: e7 to be precise
18:04imirkin_: that's quite odd that those weren't load-propagated...
18:04karolherbst: a little yes
18:04karolherbst: tobijk: could you see after which pass the mov is generated?
18:05karolherbst: just disable them one by one
18:07karolherbst: tobijk: could you give us the entire IR tree before constant and after constant filding?
18:08tobijk: karolherbst: i think i will first check the constand folding methods, where it comes from
18:08karolherbst: it will be obvious
18:19tobijk: karolherbst: ah its a killed MAD where we use the const and we end with a double mov: mov reg1 < val; mov reg2 < reg1; mul regx reg2
18:21karolherbst: yeah, that makes sense
18:21karolherbst: yep, we should be smarter about this a little
18:21tobijk: lines 173 & 594
18:21karolherbst: but mhh
18:21karolherbst: that's odd
18:22tobijk: karolherbst: ?
18:22karolherbst: well we could make the mad smarter to also pull in the immediate
18:24tobijk: karolherbst: not sure if its possible, as its a 3 reg insn
18:25tobijk: there is only space for one imm and that should be src1
18:25karolherbst: no, if we have mad imm0 imm1 imm2
18:25karolherbst: we also fold the third imm in
18:25karolherbst: currently we just do it for the first two
18:25tobijk: uhm then the imms are badly constrained
18:26karolherbst: you don't get what I mean
18:26karolherbst: if we hagve a mad and all sources are mov imm instructions
18:26karolherbst: we just calculate the entire result, not partially as we do now
18:27karolherbst: instead of have a mov chain, we pull in the third value as well
18:29tobijk: karolherbst: well ok, here we could fold src1 && src2
18:30karolherbst: no, we fold all three at the same time
18:30karolherbst: if we have three immediates, we fold all in one step
18:31karolherbst: or just check while changing the op to OP_MOV
18:31karolherbst: that you can pull in the src as well
18:31karolherbst: and no, you can never fold src1 and src2 in a mad
18:32tobijk: karolherbst: well we have only src1 and 2 here, src0 is a shader input
18:32tobijk: but src1 is 0
18:33tobijk: using this example for now (the all imm fold is fine as well though)
18:33karolherbst: again, you can't fold src1 with src2, doesn't matter what src0 is. in a mad you always have to fold src0*src1 in the first step and then fold the +src2 in addition to that
18:34tobijk: yeah thats what we do, its allright shader_in*0+1.1 -> 1.1 with a double mov
18:35tobijk: we just have to get rid of the double mov here
18:35karolherbst: exactly, and that's why we fold the src2 thing also in
18:35karolherbst: or we should do that
18:35karolherbst: and then it just disappears from alone
18:35karolherbst: no new opt needed at all for this
18:38tobijk: i'm happy with not needing it, just making sure the things it catches right now is properly eliminated
18:39karolherbst: if src2 can be loaded as an immediated value, the value itself could be moved to 0 instead of src2
18:39karolherbst: that would be the proper fix
18:39karolherbst: and in the else clause, the src2 immediate value could be added to the mul result as well
18:41tobijk: sounds fine
18:41tobijk: i'll check ADD and see where if and where we fail there
18:41karolherbst: we already know
20:36mupuf: Seems like pixmark piano does not work very well on g86 :D
20:36karolherbst: the question is, do you get more or less than 1 fps?
20:36mupuf: gputest:fur:1080p:fullscreen: 0.70 FPS
20:36mupuf: gputest:pixmark_julia_fp32:1080p:fullscreen: 3.30 FPS
20:37mupuf: that is for an non-reclocked gpu though
20:37karolherbst: I see
20:37karolherbst: it benefits linear from higher clocks though
20:37karolherbst: well shader clock that is
20:38mupuf: 22: core 400 MHz shader 800 MHz memory 600 MHz
20:38mupuf: and the boot clock is AC: core 275 MHz shader 550 MHz memory 302 MHz
20:38karolherbst: well, so the difference will be rather slim
20:38mupuf: memory clock * 2
20:39karolherbst: doesn't matter at all
20:39karolherbst: for those
20:39mupuf: and I did manage to push it to 1GHz :D
20:39mupuf: well, same for core
20:39mupuf: they can be doubled
20:39karolherbst: I see
20:39mupuf: this card has always been weird
20:39mupuf: massively over-volted
20:40karolherbst: ohh I see
20:40karolherbst: or just really good chip quality
20:41mupuf: and a bad process that does not account ofr it :p
20:41mupuf: piglit takes freaking forever to compile...
20:41mupuf:wonders how long one run will take...
20:42karolherbst: have to sleep though, a little tired
20:42mupuf: sleep tight
20:42mupuf: you had to wake up super early :)
20:42karolherbst: well, have to wake up at 7 again
20:43hakzsam: yeah, 7 is insane :)
20:43mupuf: hmm, seems like I screwed up the state of the gpu quite well :D
20:43karolherbst: hakzsam: ohh, I had to wake up at 5 for the plane today ;)
20:44hakzsam: worst, yeah
20:44karolherbst: it is always fun if you meet new people you already talked a while on IRC, cause afterwards you read that stuff differently
20:45mupuf:read that with a german accent
20:46karolherbst: it was so weird on the airport though
20:46imirkin_: mupuf: yeah, pixmark piano fails on g8x - i know about it, and i have some half-fixes, but not complete yet
20:46imirkin_: mupuf: looks like crysis is able to hit some of the same issues with st/nine on fermi/kepler, so that has been bumped in priority
20:46karolherbst: there were some germans with like a really heavy south german accent, and the first 10 minutes I was like: "do I understand this or what language is this?" :D
20:46mupuf: oh, crysis! About as old as this GPU :D
20:47mupuf: imirkin_: good to know!
20:47mupuf: it seems to have messed up the state quite badly :D
20:47imirkin_: unfortunately my "fixes" make it go from misrender to hang
20:48mupuf:gets a lot of errors in dmesg instead
20:48karolherbst: bye bye
20:49hakzsam: mupuf, speaking about piglit, it should not crash on nv50 btw, but it's going to be very long
20:49hakzsam: karolherbst, night
20:49mupuf: karolherbst: night!
20:49hakzsam: mupuf, at least, it worked fine with mesa 12.0
20:49mupuf: hakzsam: well, it did take 30 minutes to compile mesa
20:49mupuf: and about 40 minutes for piglit
20:53mupuf: seems like volplosion is even better
20:53mupuf: complete hang
21:02hakzsam: imirkin_, SHLADD v2 is on the way
21:02imirkin_: what did i hate about the first one?
21:02hakzsam: not so much, only minor things
21:03imirkin_: ah good
21:03hakzsam: look at the v2 tags
21:03hakzsam: (in the commit msgs)
21:03mupuf: hmm, the jetson tk1 is orders of magnitude faster than this laptop
21:06hakzsam: mupuf, which branch should I get for testing trtt's apitrace GUI btw?
21:06imirkin_: mupuf: why are you building things on it?
21:06hakzsam: for CI
21:06mupuf: imirkin_: not building, building was slow but doable
21:06mupuf: I am talking about piglit!
21:06imirkin_: mupuf: ah yeah.
21:06mupuf: it'\s been a solid 5 minutes I started the command ... it is still chewing on it
21:06mupuf: and has yet to start one test
21:07mupuf: ah, here we go!
21:07imirkin_: right... that's the "parse every shader test file" logic :(
21:07mupuf: let's hope some of this gets cached
21:07mupuf: otherwise ... well, I still don't give a shit about it
21:07mupuf: because it will still be fast enough for doing continuous testing
21:07mupuf: even if it takes a week
21:09mupuf: as for building, I am thinking about using icecream, which is a replacement for distcc
21:13hakzsam: mupuf, I'm profiling warps_launched with the gui :)
21:13hakzsam: oh it crashed
21:32hakzsam: mupuf, reator crashed again
21:32hakzsam: running: spec/!opengl 1.1/max-texture-size
21:33hakzsam: that test used to work
21:33hakzsam: but not really surprising though
21:33mupuf: hmm, newer kernel?
21:34hakzsam: no, I use my own nouveau module
21:34hakzsam: because the latest kernel is buggy
21:34hakzsam: but definitely unrelated to that fail I think
21:35hakzsam: I will try again without that test
23:01mupuf: hmm, compiling mesa from 40k commits ago is ... funny
23:02mupuf: for some reason, it did not even know about the wayland egl platform
23:04mupuf: hmm, right, libdrm_nouveau 1
23:04mupuf: well, let's be more realistic :D
23:08mupuf: 20k commits seems alright so far. That corresponds to a bit over 2 years ago, instead of 5