00:55 Lyude: Has anyone here played around with the fancy G-sync displays? Not to the point of actually getting g-sync working, but moreso trying to use them with non-nvidia hardware as normal displays
00:56 Lyude: I ask because I'm trying to fix some issues with i915 on one for one of my friends, and this thing is absolutely bizarre. i2c transactions seem to just always get deferred, but everything else works
00:56 Lyude: and the sink doesn't seem to define any special i2c rate either
01:18 imirkin: Lyude: afaik g-sync displays are supposed to work as regular displays
01:18 imirkin: but you can do fancy things to them to enable the fancy features
01:21 Lyude: imirkin: huh. that doesn't entirely seem to be the case here
01:21 Lyude: what's weird is it works 100% outside of i2c over dp aux transactions
01:22 Lyude: but since i2c over dp aux doesn't work we don't get an edid
01:22 imirkin: so you basically don't get edid?
01:22 Lyude: yeah
01:22 imirkin: is this on nouveau, or nvidia?
01:22 Lyude: imirkin: nouveau and i915
01:22 Lyude: both seem to have the same behavior
01:22 Lyude: I am tempted to try tracing nvidia to see what they do
01:22 imirkin: ok, well someone swears that when nouveau switched to the generic i2c interface, edid fetches broke
01:23 imirkin: there were some bugs with zero-size transactions that we fixed, but issues for that person persisted
01:23 Lyude: these all happen to be zero size transactions according to dmesg
01:23 Lyude: have a bug report?
01:24 imirkin: https://bugs.freedesktop.org/show_bug.cgi?id=103351
01:24 imirkin: no one mentioned, at the time, anything about g-sync
01:25 imirkin: it makes absolute ZERO sense that the thing to *fix* those transactions broke things for him
01:25 imirkin: but you could flip things over to using the non-generic thing all the time on nouveau and see if it helps
01:29 imirkin: ok... going to tackle that stupid textureLod(0) -> levelZero = true regression
01:29 imirkin: so much hack
02:35 imirkin: ok. texlod thing fixed. i'll need to test it on maxwell+ -- i forget if the padding was really necessary there or not
02:42 JordiGH: http://paste.debian.net/1064536/
02:42 JordiGH: So, nouveau has been freezing my laptop.
02:42 JordiGH: Got those errors above --^
02:42 JordiGH: But no freeze yet.
02:43 imirkin: that's a command submission rejection
02:43 imirkin: probably requesting too much vram or something
02:43 imirkin: we don't handle that well at all
02:44 JordiGH: Oh?
02:44 JordiGH: I'm gonna try to crash it.
02:44 JordiGH: Let's open more windows.
02:46 JordiGH: Hm, still no crash, managed to get a few more errors, though: http://paste.debian.net/1064537/
02:46 JordiGH: Google Maps on Firefox is what seems to do it.
02:48 JordiGH: Dammit, when I wanna repro a crash that's when nothing happens.
02:49 JordiGH: I was getting fed up with crashes so I tried the nvidia blob.
02:49 JordiGH: It's dog-slow on this machine.
02:49 JordiGH: So I went back to nouveau which is speedy but crashy.
02:50 imirkin: what gpu is this?
02:51 JordiGH: Old one. 8400 geforce something something, let me find out.
02:52 imirkin: yeah ok
02:52 imirkin: probably 128 or 256mb vram?
02:52 JordiGH: geforce 8400m
02:52 JordiGH: Hm, how do I find that out?
02:53 imirkin: should be printed when nouveau loads
02:53 JordiGH: [ 36.551910] nouveau 0000:01:00.0: DRM: VRAM: 128 MiB
02:55 imirkin: right
03:02 JordiGH: Well, I got my wish.
03:02 JordiGH: It crashed.
03:02 JordiGH: But the ssh connexion died and I couldn't get any more output.
03:14 JordiGH: I wonder what are the odds of me being able to fix this.
03:14 JordiGH: nouveau works so well, but why does it crash? :-(
03:14 JordiGH: I am particularly impressed that it works a lot better than the blob.
03:16 imirkin: with tesla-era gpu's there are a handful of unrelated issues
03:17 imirkin: but all crash-worthy
03:17 imirkin: my guess is something was wrong with the blob setup for you, it should be faster
03:17 JordiGH: Blegh, I'd rather have my crashy freedom than the blob.
03:17 imirkin: except a few bits will be faster in nouveau, but all GL stuff will be faster with blob
03:17 JordiGH: Everything was slower with the blob.
03:17 JordiGH: Even Wesnoth.
03:21 imirkin: skeggsb: running into a fun little issue -- some genius game has 1024+ textures that are all resident (and bindless)
03:21 imirkin: skeggsb: which of course makes it impossible to submit due to the max gem handles thing...
03:51 imirkin: heh, and without bindless enabled, hitman is back to OOR_ADDR errors
03:51 imirkin: which is what we saw last time, but never figured them out.
03:51 imirkin: so i think hitman never worked properly
04:10 imirkin: or maybe the OOR_ADDR's are OK? iirc that's just out-of-bounds constbufs...
04:11 imirkin: not sure we can control that
05:42 imirkin: skeggsb: [1077805.500081] nouveau 0000:02:00.0: imem: OOM: 00040000 00001000 -28
05:43 imirkin: what is that? (on a GK208)
05:45 imirkin: as part of that, i get GL_OUT_OF_MEMORY errors in the app, which i think means that nouveau_bo_new failed (potentially in conjunction with NOUVEAU_BO_MAP)
09:21 imirkin: karolherbst: i know why the indirect draw dEQP's fail -- they use GL_FIXED, and that goes down a different draw path for us (coz it needs conversion)
09:21 imirkin: i don't quite know how to fix it off-hand though.
17:45 imirkin: yay, got one of these on a dEQP GLES31 run -- [1093207.579431] nouveau 0000:02:00.0: fifo: SCHED_ERROR 0a [CTXSW_TIMEOUT]
17:48 imirkin: karolherbst: i also get a bunch of failures on stuff like dEQP-GLES31.functional.atomic_counter.get_inc.1_counter_1_call_10_threads
17:48 imirkin: i think this is some of the missing cache invalidation
17:52 karolherbst: mhhh
17:52 karolherbst: never run the deqp GLES31 thing I believe
17:53 imirkin: oh ok
17:53 imirkin: karolherbst: you have a maxwell or later plugged in, right?
17:54 karolherbst: imirkin: currently at fosdem
17:54 imirkin: oh right. enjoy!
17:54 karolherbst: but I have a pascal in my laptop
17:54 imirkin: well, if you feel like it, play around with https://patchwork.freedesktop.org/patch/282652/
17:56 karolherbst: yeah, already saw that you sent out that patch
17:56 karolherbst: imirkin: regarding that TODO, how are tripple regs aligned?
17:58 karolherbst: but I guess there are aligned to 4, otherwise it would aready cause issues
18:07 imirkin: karolherbst: yeah, triples are aligned to 4. that's why we only fill it up to 3
18:07 imirkin: which backfired when we removed 1 and then it was aligned to 2 ;)
18:07 imirkin: but mostly i want to make sure what i did doesn't break stuff on maxwell
18:07 imirkin: and then it'd be good to try to just remove that maxwell logic and see if things still work
18:07 imirkin: iirc they don't -- i looked into that in the early maxwell days, but it could also have been 75 other things
18:51 imirkin: interesitng. i think this test consistently triggers a CTXSW_TIMEOUT for me: dEQP-GLES31.functional.geometry_shading.query.primitives_generated_instanced
18:56 imirkin: fun. dEQP-GLES31.functional.separate_shader.interface.same_name_vertex_smooth_fragment_smooth has an error in the PhiMovesPass
18:59 imirkin: aha. that's a local change from pendingchaos. oops.
19:12 imirkin: karolherbst: i'm leaving some notes in the nouveau-cts trello about the various deqp failurse
20:26 imirkin: ok, i think i can solve that indirect draw thing by just not the draw indirectly
20:26 imirkin: seems like enough of a corner case
21:11 imirkin: karolherbst: good news -- deqp GLES31 is almost all passing too. i'm fixing the indirect stuff, and then there's 3d images and the atomic counter weirdness.
21:14 imirkin: i'm going to try to implement 3d images by de-tiling the whole image the first time it's bound to 3d