00:17 anholt: nir question: from a nir_variable, how do I figure out how many ubo blocks it represents and what the type is per ubo?
00:18 anholt: I'm trying to figure it out from the linker and getting lost in glsl types
00:26 bnieuwenhuizen: anholt: isn't a variable either an ubo or an array of ubos?
00:27 anholt: bnieuwenhuizen: how do I distinguish a ubo array (float[3]) from an array of 3 single-float ubos?
00:28 bnieuwenhuizen: I think if it isn't an ubo array the type is some form of block type
00:31 bnieuwenhuizen: hmm, looking at the spirv code not entirely sure though
00:33 bnieuwenhuizen: I think it is safe to say though that if the type of the variable itself is an array it is an ubo array
00:52 anholt: checking if the thing under the array is interface seems to maybe be the trick?
00:58 anholt: yeah. but then I run into the problem that multiple vars can be in one ubo block, and I don't have the start offset for them within the ubo.
00:59 anholt:knew this some months ago
00:59 zmike: anholt: oh this is my wheelhouse
01:00 zmike: bool ubo_array = glsl_type_is_array(var->type) && glsl_type_is_interface(type);
01:00 zmike: if (var->data.location > 0 && !ubo_array && var->type != var->interface_type)
01:00 zmike: is what I use to detect ubo sub-blocks
01:00 zmike: interface type indicates the overall ubo block type
01:01 zmike: and data.location is the block index
01:01 zmike: (this is after explicit io)
01:01 zmike: so generally speaking each nir_variable should represent exactly 1 block
01:03 anholt: var->data.location does not appear to be a block index, I think you mean .driver_location.
01:03 zmike: I don't
01:03 anholt: .location is the uniform variable number that you can look up an offset for in the GL API.
01:04 zmike: hm
01:04 zmike: let me check another thing...
01:05 zmike: anholt: maybe a good question here is what are you trying to do with this knowledge?
01:06 bnieuwenhuizen: what do you mean with block index if not the location queryable by the API?
01:06 zmike: well there's different types of this too
01:06 zmike: there's the gpu_shader5 ubo arrays
01:06 zmike: where each array member is a ubo block
01:07 zmike: and then there's the basic ubo block extension
01:07 zmike: I don't remember the name
01:07 zmike: if you have an array of ubos I think you should only get the base array variable
01:08 zmike: for a single ubo block then you can get sub-block variables from explicit io
01:08 bnieuwenhuizen: yes
01:08 zmike: which have data.location set as the index within that block
01:09 zmike: so essentially if you have a nir_variable, 'type' is either going to be a sub-block type from explicit io or it will be array<ubo block> type
07:21 imirkin: i'm getting some quality warnings with deqp in line drawing:
07:21 imirkin: Interpolation was calculated using coordinates projected onto major axis. This method does not produce the same values as the non-projecting method defined in the specification.
07:21 imirkin: e.g. dEQP-GLES3.functional.rasterization.interpolation.basic.lines
07:22 imirkin: does anyone have any clue as to what it's talking about? does it want noperspective interp for lines?
10:14 Sumera[m]: danvet: if I split the last v3 patch I sent into a patchset, then um, do I add just one version changelog for the entire patchset, or a different version change log for each patch?
10:15 danvet: hm maybe keep the log on the first main patch that does the split
10:15 danvet: and annotate there that you split out the writeback patch
10:15 danvet: or something like that
10:15 Sumera[m]: alright
10:16 danvet: or on the cover letter works too I guess
10:24 MrCooper: ajax anholt: you can also disable the shared runners for your fork on https://gitlab.freedesktop.org/<username>/mesa/-/settings/ci_cd , then it'll only use any personal runners
10:27 MrCooper: ajax: https://gitlab.freedesktop.org/mesa/mesa/-/pipelines/252956/dag (try hovering the cursor over the pipes)
14:00 pendingchaos: freedreno CI looks broken: https://gitlab.freedesktop.org/mesa/mesa/-/pipelines/253065
14:10 hakzsam: yeah...
14:12 MrCooper: anholt robclark: ^
14:24 emersion: hi, is it possible to get this merged? it's been reviewed already. https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8086
14:25 hakzsam: emersion: done
14:25 emersion: thx!
14:30 MrCooper: interesting MR number, luckily Intel haven't claimed trademark on it yet ;)
14:33 danvet: jstultz, Subject: [PATCH RESEND v2 1/2] dma-fence: allow signaling drivers to set fence timestamp <- can you do final review and then push this?
14:33 emersion: lol
14:33 danvet: or someone who cares about android in upstream sufficiently :-)
14:33 danvet: imo looks reasonable now overall
15:30 Vanfanel: emersion: with the kernel changes you mentioned yesterday, the cursor will stop being scaled on the primary plane. That will happen on the ATOMIC interface, right? Might be a dumb question because I guess LEGACY on AMDGPU is really ATOMIC in disguise, so to say
15:30 Vanfanel: emersion: I mean: it will affect both interfaces, right?
15:31 Vanfanel: Right now, I am seeing on AMDGPU that the cursor is scaled without me having configured the cursor plane
15:31 Vanfanel: so I guess your recent changes will change that behaviour
15:34 emersion: yes, it'll affect legacy as well
15:35 emersion: if you use scaling, no cursor plane for you
15:41 Vanfanel: emersion: I am not using drmModeSetPlane() on LEGACY anymore, just drmModeSetCrtc(). So I don't manipulate planes there. I have ditched the idea.
15:42 ajax: is there a reason the meson-armhf job has LLVM_VERSION pinned to 7, and also -Dllvm=disabled ?
15:44 Vanfanel: emersion: back to something I didn't get clear: is it a bad idea to use ATOMIC for the PRIMARY PLANE and LEGACY for the cursor plane?
15:44 Vanfanel: at the same time Imean
15:44 Vanfanel: since they are different planes, there should be no problem, right?
15:56 emersion: will fail on amdgpu
15:56 emersion: because scaling
15:57 emersion: it ddin't seem like your rendering loop was correct
15:59 Vanfanel: emersion: maybe I could just ditch scaling. SDL2 pre-scales using GLES2 anyway. Without scaling, I don't need planes and I can simply set the CRTC props to read the FB (given the FB and the CRTC video mode match) and forget about planes, right?
15:59 Vanfanel: emersion: that last question is for ATOMIC
16:00 emersion: then you don't need atomic at all
16:01 Vanfanel: emersion: will drmModeSetCrtc() keep woring in the upcoming years? I thout legacy was going to be phased out...
16:01 Vanfanel: *working
16:01 Vanfanel: emersion: and drmModePageFlip(), etc
16:02 emersion: the legacy API will keep working, because a whole lot of user-space depends on it
16:02 emersion: it just won't get new features
16:03 Vanfanel: emersion: so if I stop using planes directly (ie: no scaling), your recommendation is to stay with legacy right? Its much easier to maintain anyway.
16:09 Vanfanel: emersion: however, "fenced" pageflips are not possible with the LEGACY interface, are they?
16:10 Vanfanel: so I guess ATOMIC would still be better for something like SDL2 (where games are senstitive to video ouput lag). But maybe I am wrong on this.
16:13 emersion: what do you mean by "fenced"? explicit sync?
16:21 MrCooper: explicit sync doesn't automatically result in lower latency, nor is it required for low latency
16:23 Vanfanel: emersion: yes, explicit sync. I had heard it being called "fenced"
16:25 Vanfanel: MrCooper: So, in terms if low latency, drmModePageFlip() is as good as it gets?
16:26 MrCooper: it can be worse in theory, but only if something else adds additional implicit fences before the flip completes, which normally isn't the case
16:27 emersion: in terms of latency, you'll probably want to perform the page-flip as close to the deadline as possible, because page-flips can't be amended
16:28 MrCooper: ajax: 257415863b8431214f9eefa47df910053007c053 "ci: Remove LLVM from ARM test drivers." disabled LLVM for that job but didn't remove LLVM_VERSION
16:32 Vanfanel: MrCooper: I understand now. Well, since X-less SDL2 isn't doing anything that could add implicit fenced, I guess there is no advantage in explicit flips.
16:33 Vanfanel: emersion: Well, pageflip is done as soon as the SDL2 API sends an SDL_SwapWindow() call, which does not depend on me but the games code
16:39 kennylevinsen: You could behave like a compositor does: content is submitted by the API, but pageflip is driven asynchronously and just sample the most recent submission at time of flip
16:39 kennylevinsen: Or, provide a means to get the relevant timings so the application itself could decide to swap "at the right time"
16:41 ajax: huh, okay
16:41 ajax: MrCooper: thanks
16:41 ajax: wonder if it's worth having an actual qemu-arm32 job to cover that... probably not? if we've already got i386?
16:42 Vanfanel: kennylevinsen: in SDL2, apps decide when to swap. Maybe you mean telling the apps to "ask for pageflip as late as possible, just before the vsync arrives". But the SDL2 API does not hape any means for that.
16:43 Vanfanel: kennylevinsen: well, I guess any app can measure the vblank period and issue flip as tight as possible to the end of the period
16:44 Vanfanel: kennylevinsen: the only thing I can do from the KMS/DRM backend could be send the pagelip issue as late as possible...?
16:50 kennylevinsen: Lowest latency is achieved by having content render complete just in time for pageflip deadline. Your options are to ensure that render starts as time is running out (delays, timing information, etc. - this is called frame scheduling), or by letting render run at full blast, grabbing the last rendered frame for flip when time comes.
17:06 emersion: even if you don't do frame scheduling, you'll want a proper rendering loop
17:06 emersion: issuing a page-flip when the client submits a buffer won't work if the client can do so anytime
17:07 emersion: you might get lucky if the client doesn't submit frames too often
17:41 alyssa: does piglit work with python3?
17:41 alyssa: it doesn't look like python2 numpy is packaged in debian anymore
17:45 alyssa: It looks like it should work, maybe just broken cmakefile
17:51 alyssa: cmake is a reminder of everything good about meson .-.
17:54 dcbaker: I should really finish that port...
17:54 alyssa: dcbaker: :| in the mean time any tips for getting cmake to build?
17:54 dcbaker: piglit should work with python3
17:55 alyssa: Could NOT find PythonNumpy (missing: PythonNumpy_STATUS) (Required is at least version "1.7.0")
17:55 alyssa: python3-numpy/testing,now 1:1.19.4-1+b1 arm64 [installed]
17:55 Lyude: alyssa: yeah cmake is terrible
17:55 dcbaker: do you have two versions of python3 by chance?
17:55 dcbaker: piglit's cmake is especially bad
17:55 Lyude: it's just autotools the sequel
17:55 dcbaker:is to blame for much of that
17:55 alyssa: dcbaker: Just 3.9
17:55 alyssa: which piglit maybe doesn't know about either?
17:56 alyssa: I also have python 2.7
17:56 alyssa: and `python` is 2.7, not 3.9 which might be part of the problem
17:56 dcbaker: it doesn't know about 3.9
17:56 dcbaker: -DPython_ADDIONAL_VERSOINS=3.9 to cmake should fix it
17:56 dcbaker: without the typo of course
17:56 dcbaker: s/type/typos
17:57 alyssa: alyssa@odroidn2:~/piglit$ cmake . -DPython_ADDITIONAL_VERSIONS=3.9
17:57 anholt: cmake, more like sighmake.
17:57 alyssa: still same error
17:57 alyssa: anholt: Ψmake
17:57 dcbaker: did you clear your cmakecache?
17:57 alyssa: my.. what?
17:57 alyssa: I can barely use meson, I don't know what I'm doing
17:58 dcbaker: rm -r CmakeFiles
17:58 alyssa: ---yeah, rm ..cache.txt fixes that
17:58 dcbaker: yay cmake
17:58 dcbaker:knows what do with today now
17:58 Lyude: dcbaker: convert piglit to cmake?
17:58 Lyude: erm
17:58 Lyude: *meson
17:59 dcbaker: finish converting piglit to meson
17:59 Lyude: yay
17:59 dcbaker: I already got started
17:59 alyssa: ok, yeah, it's building now
17:59 alyssa: this odroid should keep my desk nice and warm. thank you for the help!
18:02 dcbaker: I opened 3.9 to add support upstream
18:02 dcbaker: https://gitlab.freedesktop.org/mesa/piglit/-/merge_requests/448 to add 3.9 s
18:02 dcbaker:needs more coffee
18:11 bl4ckb0ne: is there a timeline for kicking cmake and keeping only meson?
18:17 MrCooper: alyssa: piglit works fine here with python3 only (and python as a symlink to it)
18:19 alyssa: MrCooper: ack, then it was python symlinked to python2 that broke things :)
18:20 dcbaker: come to think of it, I removed python2 support from piglit a while back
18:25 alyssa: also I think libxbkcommon-dev needs to be added to the ubuntu/debian apt install list in the readme
18:25 alyssa: libxkbcommmon-dev
18:47 anholt: kusma: can we get some help on how to find the generated docs online from one's pipeline?
18:53 exit70[m]: hey hey wondering about the state of mesa demos again; it has not seen a release for awhile (almost 3 years)
18:55 karolherbst: ehh.. I think I've found a useful chromium extension for text snippets https://github.com/carlinyuen/ChromeAutoTextExpander
18:55 karolherbst: I want to use it for gitlab review tags and such
18:55 karolherbst: seems to work alright
18:56 anholt: exit70[m]: probably because it's unchanged for 3 years.
18:56 karolherbst: no idea if it can be trusted though
18:58 exit70[m]: anholt: from what i see quite the opposite
19:14 zackr: So which one of the incredibly smart and gorgeous people do I need to butter up nowadays to get drm-misc commit access for me and sroland for vmwgfx work?
19:15 alyssa: ....smart and gorgeous?
19:16 ajax: this is a social engineering technique known as "flattery"
19:16 zmike: !
19:16 alyssa: ajax: *confused puppy dog head tilt*
19:16 ajax: and contrary to received wisdom it does sometimes get you somewhere
19:16 zackr: and stylish?
19:16 zackr: oh, i can keep going
19:17 zmike: well now I know you're talking to me
19:17 imirkin: zackr: unfortunately none of the people who can help you fit your description =/
19:18 alyssa: zmike: and I know zackr isn't talking to me
19:18 zmike: imirkin is right though, I can't help with this
19:18 zackr: All this modesty is suffocating me
19:18 alyssa: I have been called a great many things but stylish is not one.
19:19 ajax: i can do the acl change bit but i'm not really the drm-misc tree owner
19:19 imirkin: zackr: in reality, davnet can likely assist with the approval process. no clue what that is though.
19:20 zackr: ajax: because you're still my hero?
19:20 ccr: :D
19:20 zackr: imirkin: ah, sounds good
19:23 zackr: you can't even imagine what it took to join irc again, i had to web search "irc clients people use nowadays", then yell at kids for being all over my lawn, then i couldn't remember what nick i used, it was very stressful
19:26 imirkin: zackr: i'm with the kids using hexchat, but i assume bitchx works just as well as it did
19:29 dcbaker: jenatali: I can see it from matrix
19:30 dcbaker: Did you authenticate with nickServer
19:30 kusma: anholt: What do you mean?
19:30 anholt: kusma: someone puts up an MR changing the docs. I want to see what the rendered docs look like.
19:30 kusma: anholt: There should be artifacts, but I'm not 100% sure we upload them when testing, maybe only from master...
19:30 jstultz: danvet: i'll take a look at it, thanks for the heads up
19:30 anholt: we had this at one point
19:31 kusma: anholt: I think maybe we have it for mesa3d.org but not the mesa docs, but I can take a look.
19:31 kusma: anholt: should be easy to add, though.
19:31 anholt: that would be a huge help for docs work
19:32 kisak: as a handle in a text interface, I could at best call myself "Monospace Regular" and quite readable, but not gorgeous per say...
20:58 imirkin: anholt: why the crusade against glsl_to_tgsi? a ton of effort has gone into making sure it produces Good Things, at least for nouveau, all the way through. a glsl -> nir -> tgsi -> nv50 ir path nor glsl -> nir -> nv50 ir path will have that sort of validation.
21:00 alyssa: Pretty sure it's a crusade against tgsi
21:03 imirkin:sighs
21:04 alyssa: 🤷
21:05 Lyude: can that validation not be added onto NIR?
21:05 ajax: is Good Things here a question of correctness or optimization?
21:06 imirkin: ajax: both
21:07 imirkin: Lyude: validation that emitted code is right? i don't think that's in NIR's purvue
21:07 ajax: do we have, like, shaderdb runs we can use for a baseline?
21:07 imirkin: shaderdb is certainly a thing
21:07 imirkin: i.e. you can run it against a db, and get stats
21:07 imirkin: that doesn't really tell you whether it's right
21:08 ajax: sure
21:08 ajax: but my thinking here is, if piglit doesn't regress on a few representative cards, and shaderdb doesn't massively regress...
21:09 ajax: you are _probably_ in good shape?
21:09 imirkin: i'm in good shape now
21:09 ajax: the burden of work is certainly on the people proposing the change, don't get me wrong
21:09 imirkin: i've fixed hundreds of bugs which occur in games but not in piglit
21:10 ccr:starts a wave
21:10 Lyude: shouldn't someone write tests to try to exercise those bugs then?
21:10 imirkin: ccr: like a goodbye to the years of validation?
21:11 imirkin: Lyude: yes, a well resourced team sure *would* be nice
21:11 ccr: imirkin, nah, more like cheering at you and everyone else here who work on things
21:12 Lyude: imirkin: i mean, sure, but if there's no test you're leaving more work for yourself in the end anyway.
21:14 imirkin: how so? it works fine now.
21:17 Lyude: well, it's not really a safe bet to assume that code is never going to break because it worked once.
21:17 imirkin: something like TGSI presents a nice ABI, and as long as the emitter isn't too perturbed, it's proven to be a reasonable one.
21:19 kusma: anholt: I guess this is what you want? https://gitlab.freedesktop.org/mesa/mesa/-/jobs/6548322/artifacts/file/public/index.html
21:19 kusma: anholt: that's from https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8398
22:19 anholt: imirkin: The TGSI frontend accounts for 1% of all mesa code. Removing it it cuts our build and link times, cuts our binary size (285k so far), cuts complexity in st_program.c (which I feel like marek, tarceri, and occasionally me after a lot of work are basically the only ones that can make sense of it), and once we get this then we're a short step away fropm killing a bunch of slow GLSL IR optimizations.
22:20 anholt: sorry, not 1% removed yet. had some bad stats in my head
22:20 imirkin: anholt: you should flip that explanation around
22:20 imirkin: "kill a bunch of slow glsl ir optimizations"
22:21 imirkin: would be the selling point, in my mind
22:21 imirkin: do you have any benchmarks showing that it's faster?
22:22 anholt: only shader-db stats on softpipe originally where it's a significant instruction count win, I don't have any hw that consumes tgsi to actually test on.
22:23 anholt: (11% of instructions back when I first flipped to using NTT)
22:23 imirkin: i meant compilation
22:23 imirkin: presumably the IR optimizations are slow at generating code, not in the code that they run
22:24 imirkin: i'm not particularly concerned about (tgsi) instruction counts -- nouveau has an optimizing compiler
22:24 imirkin: i'd rather have more instructions faster than fewer instructions slower
22:26 anholt: set up drm-shim for shader-db, and I can grab stats (and it would probably be helpful for sanity-checking my input to nouveau)
22:26 imirkin: pointers to drm-shim?
22:26 imirkin: i've only heard of it
22:26 anholt: src/drm-shim
22:26 imirkin: in?
22:27 anholt: mesa
22:27 imirkin: ah ok
22:27 imirkin: thanks
22:29 imirkin: anholt: i don't see any device actually implementing these in src/drm-shim
22:29 imirkin: does that live elsewhere?
22:29 anholt: src/<vendor>/drm-shim
22:29 imirkin: gotcha
22:30 imirkin: will see how feasible it is. looks simple, but devil's in the details
22:31 imirkin: presumably having the hw in my system should not prevent me from testing out the shim...
22:31 anholt: env DRM_SHIM_DEBUG=1 will tell you where it put your device
22:33 ajax: dang. why does that only exist for arm gpus
22:34 anholt: and intel!
22:34 ajax: (because nobody's done it for the others yet, i know,)
22:34 imirkin: anholt: where is it for intel?
22:34 ajax: there's not src/intel/drm-shim?
22:34 anholt: toos/
22:34 anholt: tools/
22:34 imirkin: must not be called 'drm-shim'
22:35 anholt:offers up git grep
22:35 dcbaker: I don't think we have one
22:35 anholt: src/intel/tools/intel_noop_drm_shim.c
22:35 imirkin: src/intel/tools/intel_noop_drm_shim.c:#include "drm-shim/drm_shim.h"
22:35 imirkin: heh
22:36 imirkin: anholt: totally unrelated, i don't suppose you know anything about line drawing? i got a weird "quality warning" from dEQP, no idea what it means
22:36 anholt: I know nothing except "line drawing on all hardware is an embarassment. don't draw lines, it will only bring you sadness"
22:36 imirkin: sounds like we're on the same page then
22:37 anholt: signed, someone that tried to use lines to draw in x11.
22:37 imirkin: lol
22:37 anholt: there was a glorious page from the r100 era comparing line drawing on every vendor. my impression is things have not significantly improved in the last decades.
22:37 keithp: nope
22:38 imirkin: the message was "Interpolation was calculated using coordinates projected onto major axis. This method does not produce the same values as the non-projecting method defined in the specification."
22:38 ajax: the way to draw x11 lines in gl is to implement the line hit test inside the shader and draw a quad over the bounding box
22:38 anholt: I think that's marked just a quality warning because whoops, turns out lots of hw projects.
22:39 imirkin: but what is it talking about? interpolation of varyings?
22:39 imirkin: should i force noperspective when drawing lines?
22:39 imirkin: (i guess with polygon mode it may be annoying)
22:41 imirkin: or is it talking about the actual pixels which are drawn as part of the line?
22:41 imirkin: (i tried to RTFS, but ... it wasn't so easy to follow)
22:41 anholt: interp of varyings
22:41 anholt: aw crap, I do know something about lines
22:42 keithp: oops
22:43 imirkin: anholt: ok, thanks
22:45 imirkin: anholt: back to the drm shim, basically i just do a strace to see what ioctl's get called on "startup" and make sure they're all "handled"?
22:51 anholt: imirkin: I don't even go that far, I just implement no ioctls at the start and then add them until shader-db runs :)
22:51 anholt: it dumps the number when one's missing.
22:51 imirkin: ah cool, will do
23:13 anholt:discovers that testing KHR-GL30 in addition to KHR-GL33 actually gets at some different code :(
23:13 imirkin: uff
23:13 imirkin: i thought the KHR suites were incremental
23:13 imirkin: oh, maybe it tests compat
23:13 imirkin: vs core
23:13 anholt: compat vs core, yep