01:14 imirkin: Lyude: fwiw it all works fine on GP108
01:15 imirkin: Lyude: modetest -s 48:1920x1200 -P 40@43:640x640+100+100
01:15 imirkin: that lets you see a pattern better
01:15 imirkin: but you can also do 64x64 (tested, worked ok)
01:15 imirkin: i also have some cairo thing which draws little marks every so often on the image
01:16 Lyude: Hm, alright, I'll swap out and try my pascal GPUs tommorow
01:16 imirkin: this is on kernel 5.0.18
01:16 imirkin: + various patches, hopefully nothing affecting this though
01:16 Lyude: Mainline nouveau?
01:16 imirkin: let's check...
01:16 imirkin: "5.0.18+"
01:17 imirkin: i mean, basically mainline nouveau
01:17 imirkin: i might have had a handful of patches in here
01:17 imirkin: nothing major
01:21 Lyude: imirkin: btw-does it generate a similar pattern on each plane?
01:22 imirkin: no
01:22 imirkin: but i also have local changes
01:22 imirkin: which may or may not be pushed?
01:22 imirkin: to make formats more configurable
01:22 imirkin: iirc it does SMPTE on primary plane by default
01:23 imirkin: and some diagonally striped thing for the overlay plane by default
01:23 imirkin: ok cool. looks like i've mostly pushed everything. lut stuff is still local.
01:24 imirkin: see commit 5d0e9dec3fb3eb019bb9fd4b1e3d32484198917f in drm
01:24 imirkin: there's a primary and secondary fill. you can change them with -F
01:24 imirkin: e.g. -F smpte,smpte if you want the smpte pattern in both primary and secondary planes
01:25 imirkin: there's also a "plain" (solid color fill), and a "gradient", which i use for 10bpp testing
01:25 imirkin: which draws the upper half at 10bpp gradient, and bottom half as 8bpp gradient
01:25 imirkin: so if you see banding differences, you have 10bpp working (either up to 10bpc, or with dithering)
01:25 imirkin: and if you don't see banding differences, then you're 8bpp all the way :)
01:30 Lyude: oh hey-300x300 works?
01:38 imirkin: hm, could be something dumb in the buffer size / alignment then?
01:39 imirkin: the min stride is 256px
01:39 imirkin: er, 256 bytes
01:39 imirkin: tbh i'm not sure i've ever tested overlays that small before
01:39 imirkin: since it's a visual test, i always like to see :)
01:40 Lyude: well igt is good at breaking things! and yeah-I think you might be right
01:51 Lyude: seems like 166x166 is as small as it goes before it starts breaking, huh
01:51 imirkin: heh
01:51 imirkin: what format?
01:51 imirkin: XR24?
01:52 Lyude: yep
01:52 imirkin: i've gotta say, that's not _the_ most obvious size break...
01:53 imirkin: worth trying other gens too -- could be something specific to kepler we're missing
01:53 imirkin: Lyude: btw, as long as you have that kepler plugged in, mind running a piglit for me?
01:53 imirkin: no special mesa needed
01:54 Lyude: imirkin: sure send a branch
01:54 imirkin: https://patchwork.freedesktop.org/patch/347445/
01:54 imirkin: build + run bin/glsl-1.50-transform-feedback-builtins
01:54 imirkin: and let me know if it passes or fails. i'm guessing it passes, since it worked on a GK208 apparently
01:54 imirkin: and it fails on GM107 and GP108
02:12 Lyude: imirkin: pass
02:12 imirkin: cool, thanks. That's on GK10x, right?
02:12 Lyude: yep-gk104
02:13 imirkin: so i guess they broke something with SM50
02:13 imirkin: will play with delays, maybe it's that
02:29 imirkin: yeah, messing with delays doesn't help
02:33 imirkin: and even if i put the primid/layer store second, it still fails
02:33 imirkin: so it's really something specific to storing at 0x60 with 64- or 128-wide AST ops on SM50+
05:05 imirkin: this one fails on GP108 because for some reason, MRT 2 isn't working. if i flip it to mrt0, it works fine. GTF-GL45.gtf33.GL3Tests.explicit_attrib_location.explicit_attrib_location_pipeline
05:24 imirkin: still debugging this one... GTF-GL45.gtf30.GL3Tests.transform_feedback.transform_feedback_overflow ... looks like only the final case is failing? maybe the SEPARATE_ATTRIBS case isn't being handled properly.
05:24 imirkin: oh well, will finish another day.
05:29 HdkR: imirkin: Maybe you should just avoid >32bit AST (and the load) on SM50+ :)
12:45 imirkin: HdkR: maybe. seems silly for vec4 stores.
12:49 HdkR: :)
12:51 imirkin: and it works just fine everywhere ... this is the only problem spot.
13:11 AndrewR: imirkin, just for lulz I tried modetest without parameters from (nouveaufb) console on my nv92 and kernel 5.4.6: https://pastebin.com/UTjrnqp5 . I wonder if running modetest command above with test pattern will ruin my X desktop? (if I run it from there)
13:29 AndrewR: imirkin, from within X session it just failed to find device :}
13:35 AndrewR: imirkin, so ./modetest -s 55:1440x900 -P 47@56:640x640+100+100 worked in my case, but I have to issue 'reset' on VT I run this command from for getting my bash prompt back ....
13:37 imirkin_: AndrewR: you have to exit out of modetest
13:37 imirkin_: otherwise switching back to X, it can't become master
13:37 imirkin_: and becomes very angry
13:38 imirkin_: and yeah, the prompt being gone is expected
13:38 imirkin_: just go to alt+f2 and then alt+f1 and you're good again
13:38 imirkin_: something modetest does wrong on exit i guess?
13:45 AndrewR: imirkin, do you want this piglit test on nv50-class hw? (currently copying it to tmpfs, then update + patch, and run ..)
13:46 imirkin_: AndrewR: no
13:47 imirkin_: i've already run it on a G84 anwyays
13:47 imirkin_: i have the most anachronistic set of GPUs plugged in... NV5, G84, and GP108 :)
13:48 imirkin_: i guess a TU10x would be even more, but there's no cheapo volta/turing boards yet
13:49 imirkin_: exports on nv50 work fairly differently ... and iirc there are no wide-store options
14:04 cosurgi: imirkin_: oh, wow! Great. Thanks a lot! It's in skeggsb repository, is that linux kernel source?
14:04 imirkin_: no, it's an annoyingly similar-but-different repository
14:04 imirkin_: grab the patch
14:04 imirkin_: and apply it manually a level up
14:05 imirkin_: or replace "drm/" with "drivers/gpu/drm/" in the patch
14:05 imirkin_: you could also try to play the out-of-tree driver game, but i've failed almost every time i've tried
14:05 imirkin_: so now i just don't try.
14:08 cosurgi: OK. I will download latest kernel source from kernel.org, 5.4.8 and apply the patch.
14:08 imirkin_: no need
14:08 imirkin_: should apply to almost any kernel
14:09 imirkin_: like 4.3+
14:09 cosurgi: currently I have 5.2.1
14:09 imirkin_: yeah, that's more than recent enough
14:09 cosurgi: should have the sources somewhere, because I compiled it by hand some time ago...
14:09 imirkin_: oh wait. i was thinking of a diff patch.
14:09 imirkin_: actually that one should be ok too? dunno
14:09 imirkin_: if it doesn't apply, grab newer sources
14:09 cosurgi: no worries, I'm used to recompiling kernel ;)
14:11 cosurgi: Though I am no sure if I will do this today. Plenty of work.. but I will try this patch this quite soon.
14:12 imirkin_: whenever.
14:12 cosurgi: Thanks a look for remembering about me! I was waiting for this patch intensely :)
14:13 cosurgi: Thanks a *lot
14:13 cosurgi: ")
14:13 cosurgi: :)
14:14 cosurgi: And happy new year 2020 !
14:14 cosurgi: Cool number 2020 ;)
14:14 imirkin_: well, i have no idea if it'll help
14:15 imirkin_: it's just a bugfix for something that was pointed out in a review of unrelated functionality
14:15 imirkin_: which could potentially be related to what you're seeing
14:15 imirkin_: and the bugfix itself is untested too
14:15 cosurgi: OK. We will know when next crash happens :)
14:16 cosurgi: *if next crash happens.
14:16 imirkin_: no. when. :)
14:16 cosurgi: :-)
14:54 AndrewR: imirkin, dev/shm/piglit/tests/spec/ext_disjoint_timer_query/simple-query.c:100: undefined reference to `glGetInteger64vEXT' hm .... (trying to build against Mesa 20.0.0-devel (git-c5ae64ebc7) )
15:02 imirkin_: AndrewR: yeah, dunno
15:02 imirkin_: sounds like you haven't rebuilt something? dunno.
15:04 AndrewR: imirkin, there is 00076ce0 T glGetInteger64v in libGL ....
15:04 AndrewR: imirkin, https://github.com/KhronosGroup/OpenGL-Registry/issues/326
15:05 imirkin_: ah, yeah - piglit's wrappers are gl.xml-based
15:05 imirkin_: but if it doesn't compile for you, it shouldn't compile for anyone...
15:05 imirkin_: it shouldn't be trying to call `glGetInteger64vEXT' directly
15:05 imirkin_: that should be #define'd to something in some header
15:23 AndrewR: moment, need to restart X (after mesa install ..just to be sure)
15:28 AndrewR: nope, same error on piglit compiation. may be piglit.git moved somewhere? I have git up to 4f9e5f783b9c359d22e9ae27b54b2e940429ead2 ("gitlab-ci: Update to current ci-templates")
15:29 imirkin_: that seems right
15:29 imirkin_: i'd do a clean build if you haven't already
15:29 imirkin_: cmake is weird.
15:40 AndrewR: imirkin, ah, it lives in libGLESv2.so.2.0.0 , probably I set some paths wrong ....
15:43 AndrewR: imirkin, just disabled gles tests for now ....
15:56 AndrewR: imirkin, ok, gles2 tests cause this, for me .....if I enable gles3 and gles1 tests piglit still builds w/o errors.
16:00 imirkin_: AndrewR: weird. maybe report in #dri-devel? haven't looked at it in ages