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