08:30 austriancoder: what is the easiest way to figure out what gl context was created and in which version - I had a quick look at some mesa debug env vars but did not found anything
09:49 danvet: agd5f, I guess you need to backmerge into your tree to catch up with all the drm-misc changes?
09:50 danvet: I got confused for a moment how luben managed to create a conflict
09:50 danvet: also I caught up with mail, disregard my first reply, I'll send out a new unified patch series with everything
10:05 asdf28: agd5f, lol what a generic nickname
13:01 alyssa: anyone know what time of the day the branch point is? 😇
13:02 kisak: dcbaker ^
13:11 pq: I wonder, in a display server that wants to do gamma-correct blending; would it be better to use an intermediate FP16 framebuffer in linear-light and then do a blit non-linearize, or blend directly into framebuffer using a blending shader that does degamma-blend-gamma for every fragment?
13:12 pq: degamma and gamma operations would involve texture lookups in the general case
13:14 pq: my feeling says to go with an intermediate framebuffer, but what would be reasons to do otherwise?
13:14 pq: cc swick
13:20 tzimmermann: danvet, can i rename igt subtests? i'd like to make the fbdev mmap test a single I/O test that checks all functionality
13:28 glennk: pq, for srgb specifically the hardware will do gamma correct blending
13:28 pq: glennk, I can't assume sRGB.
13:28 glennk: anything else is basically undefined results for alpha blending vs gamma :p
13:29 pq: and I would have to know what the hardware actually means with "sRGB" if I were to use it
13:29 pq: glennk, sorry?
13:29 glennk: there really isn't a "correct" way to do alpha blending, its really more what trade offs do you want
13:30 pq: glennk, I define correct alpha blending as occupancy-based blending in linear-light (i.e. additive) color values.
13:31 glennk: you mean separably linear per component in process color space?
13:31 pq: the question is, do I use an intermediate buffer, or have the fragment shader do EOTF-blend-EOTF^-1
13:33 pq: glennk, separable, linear, and in whatever color space it happens to be as long as it's additive
13:34 pq: quite likely the color space and EOTF is those of an actual monitor for the resulting image (content to be blended in has its own color space and EOTF, which have already been taken into account)
13:35 daniels: alyssa: dcbaker's hard drive exploded, so the branch point may not in fact be today ...
13:40 glennk: pq, is this alpha blending in context of a window system compositor?
13:41 pq: glennk, yes, I said "in a display server"
13:42 danvet: tzimmermann, yeah, but not sure that's a super great idea
13:42 danvet: stuff gets unwielding fast
13:42 danvet: tzimmermann, why do you want it all in one?
13:43 tzimmermann: the tests for mmap, read and write al operate on the same framebuffer memory. they'd have to be serialized anyway
13:46 glennk: pq, so what range of hardware?
13:46 pq: glennk, GL ES 3.0 more or less
13:47 glennk: lets split it into typical desktop gpu then if you care embedded gpus are probably better dealt with separately?
13:48 pq: What is the main difference?
13:50 glennk: pretty vastly different levels of functionality, available memory and bandwidth, and balance of compute vs pixel fill rate
13:51 alyssa: daniels: oh no :D
13:51 tzimmermann: danvet ^
13:51 danvet: tzimmermann, we don't run them in parallel on the same box
13:52 danvet: we run them in parallel on lots of machines :-)
13:52 danvet: I also thinks it's nice to have fine-ish grained results
13:52 danvet: and igt_fixture is the tool for common mmap and stuff like that
13:52 tzimmermann: so one machine only runs only read and another machine only runs write ?
13:52 emersion: glennk: so what's best on desktops, and what's best on embedded?
13:53 danvet: tzimmermann, sometimes, I'm not sure where we are with the runner running stuff together
13:53 pq: glennk, IOW, I should have both paths and choose one based on... how can I choose?
13:53 danvet: but aside from all that, I do kinda like split up results instead of monster tests
13:53 tzimmermann: that's even more confusing
13:53 glennk: emersion, pq, depends on what you want, but the best solutions are probably not the same for those two cases regardless of what criteria you pick
13:54 danvet: tzimmermann, for a somewhat extreme example kms_addfb_basic.c
13:54 emersion: (i'd just go for a blit tbh)
13:54 glennk: also embedded tends to throw in a bunch of ad hoc random hardware accelerators (or decelerators...)
13:55 pq: an intermediate buffer occupies a *lot* more memory...
13:55 danvet: tzimmermann, so if you want the shared mmap and buf, just pull the setup into the first fixture and done
13:55 danvet: instead of leaving them in a subtest
13:55 tzimmermann: ok
13:55 tzimmermann: are fixtures executed in order?
13:56 pq: but I'm worried that going repeatedly through degamma-gamma texture lookups may be slow and also accumulate errors
13:57 danvet: tzimmermann, yup
13:57 glennk: usually gamma is just a function and a couple alu ops, for a desktop gpu its nothing
13:57 pq: OTOH, the non-linearizing blit can be avoided if it can be implemented with KMS GAMMA, but then the FB has to have enough precision ->
13:57 tzimmermann: ok, thank you
13:57 danvet: without argument, stuff runs in order you expect
13:57 danvet: it also helps a bit with self documenting code
13:57 danvet: stuff in fixture is just setup stuff, not really testcase logic
13:58 danvet: often there's 0 comments about what's being tested, the blocks help a bit with that
13:58 pq: glennk, that's true
13:58 pq: glennk, but if the monitor ICC profile is measured and not designed, it's possible all we have is a LUT
13:59 pq: for the EOTF
14:00 glennk: lets start with the most common case, most computer monitors are still srgb especially office ones, and virtually all source content a window system will see is in srgb
14:01 pq: glennk, that's the very assumption we are busting here :-)
14:01 pq: this is for Wayland color management and HDR implementation in Weston.
14:01 glennk: you are extending support, not invalidating existing use cases are you not?
14:02 pq: sure
14:03 glennk: so first for this specific case, the hardware already supports srgb in both texture samplers and alpha blending units
14:04 pq: We start from the most general case which is LUTs for everything, and once that is tested to be correct and checked in CI, we can add optimized special cases while CI tells us if it breaks.
14:04 glennk: that said, you'll probably notice if you try blending with gamma correction that window shadows etc will "look wrong" as they are probably authored for srgb-space-linear blending
14:05 pq: I know
14:05 glennk: CI is currently testing srgb and not "the general case" ?
14:06 pq: the tests haven't been written yet
14:07 alyssa: grrr class on the day of the branch point, the nerve! :p
14:09 glennk: pq, i would humbly suggest starting with the currently implemented cases and CI those before rewriting the world to use LUTs
14:09 glennk: mostly as being in spirit of CI :-)
14:10 pq: This actually gives me the answer: go with the simplest solution first, make sure it works, then look at how it can be faster.
14:11 pq: glennk, well, there are a bunch of "does this picture show up right" tests.
14:15 pq: but nothing that would test that if you set up this wild color space, is the pipeline handling it right
14:15 glennk: i think as long as the compositor passes values with alpha=0 and alpha=1.0 with full accuracy as long as the rest have monotonic results you should be good to go
14:18 pq: hmm, monotonic... that's a good idea for a test sequence
14:19 glennk: its really visible with an alpha fade animation if its not monotonic, but if misses some intermediate value or is linear vs logarithmic the user won't really notice
14:23 glennk: pq, do you have any specific use cases for non-srgb non-fullscreen content?
14:25 emersion: watching a video in a web browser?
14:26 emersion: photo/video editing maybe?
14:27 pq: glennk, what emersion said. Also HDR. An even being fullscreen does not outrule having other different content on the screen at the same time.
14:28 pq: like notifications, or picture-in-picture
14:37 glennk: the hdr video in a browser window is a tricky one on most current HDR capable monitors
14:37 glennk: even with local dimming the HDR bit is done with general backlight intensity modulation
14:39 glennk: which makes the UI elements vary in intensity too
14:52 pq: glennk, to me that's a monitor defect ;-)
14:54 pq: a compositor could run in an unmanaged HDR mode where it let's the monitor do dynamic magic on the image, but in a color managed HDR mode that is not acceptable.
14:54 emersion: why do we keep getting new features that only kind-of-work for fullscreen use-cases :S
14:55 glennk: thats pretty much the description of everything isn't it?
15:22 glennk: pq, emersion how also to handle differing bandwidth requirements for ldr vs hdr output?
15:57 danvet: agd5f, so ack for merging luben's const patch through drm-misc-next?
16:44 agd5f: danvet, yes
16:49 danvet: agd5f, thx
16:50 danvet: and sorry for the confusion I caused with being somewhat all over the place
16:50 agd5f: no worries. I confused myself as well :)
17:30 karolherbst: uhh
17:30 karolherbst: *sigh*
17:30 karolherbst: get_canonical_format is just busted for BE
17:41 danvet: karolherbst, why do you still care?
17:41 karolherbst: do you really want to know?
17:45 karolherbst: anyway.. might not have to fix this function, just that this format BE stuff just looks super wrong and I don't think it was a good idea to add BE handling into u_formats.csv
19:05 airlied: (04-Nov 19:28:45) PASSED Relationals : (163654s, test 7/53) lols, only 45hrs in the end :-P
19:05 jekstrand: airlied: Woo!
19:05 jekstrand: airlied: I'm surprised you left it running. :P
19:08 karolherbst: airlied: nice
19:08 jekstrand: airlied: Looking forward to that conformance run?
19:11 karolherbst: curro: mhhhh. debugged the queue stuff a bit more and I see events with signalled fences still in the queue
19:11 karolherbst: uhm.. wait. I think I messed up my asserts
19:12 airlied: jekstrand: the machine wasn't running anything else, and I had other tasks :-P
19:14 karolherbst: duh...
19:16 airlied: jekstrand: I think for a full conformance run I'll find a faster machine :-P
19:16 airlied: and maybe llvm release build
19:17 karolherbst: ahhhhh
19:17 karolherbst: I think I am just running into a stupid c++ bug
19:17 karolherbst: it makes literally 0 sense
19:18 karolherbst: so calling queue() inside hard_event::wait gives me SIGSEGV
19:18 karolherbst: libasan time
19:22 anholt:
19:37 dschuermann: jekstrand: fyi, I've written a bunch of control flow optimizations regarding breaks (especially for single-iteration loops)as well as if-collapsing
19:38 dschuermann: (just in case someone is working on something similar)
20:50 karolherbst: uhhh
20:50 karolherbst: jekstrand:
20:50 karolherbst: vec1 32 ssa_0 = load_const (0x00000000 /* 0.000000 */)
20:50 karolherbst: vec2 32 ssa_24 = intrinsic image_size (ssa_0, ssa_0) (1, 0, 0, 8) /* image_dim=2D */ /* image_array=false */ /* format=0 */ /* access=8 */
20:50 karolherbst: :/
20:50 karolherbst: mhh
20:50 karolherbst: why does image_size have two args to begin with?
20:51 karolherbst: ahh sample index
20:51 jekstrand: karolherbst: image index and LOD
20:52 karolherbst: yeah...
20:52 karolherbst: I somehow treat is as coords for wahtever reason
20:52 jekstrand: Probably want to stop doing that. :P
20:52 karolherbst: yeah
20:57 karolherbst:should rewrite nv50_ir_from_nir
21:07 swick: glennk: if you want a general purpose compositor to show HDR content it should set the display into HDR mode at all times sine switching to HDR mode is a mode switch and changes calibration
21:09 swick: so the bandwidth difference is something you'll only have to deal with when the user "turns on" HDR in some kind of display settings
21:13 swick: not sure if it became clear but the LUT for gamma/degamma is the base case. we can lower everything into a LUT. in some cases (possibly most of the time) we have parametric descriptions which we can implement in the shader.
21:16 jadahl: swick: do you know whether that have any implications power consumption wise? (always-on HDR with "toned down" luminance via luts)
21:16 Lyude: jadahl: they can
21:16 Lyude: that's why hdr mode on panels can be toggled on/off iirc
21:16 swick: yeah, there will be
21:16 Lyude: there's even special optimization modes for ac vs dc
21:16 jadahl: I see
21:17 Lyude: speaking of which, there's some totally cool hdr backlight patches on intel-gfx that have been there for weeks now and need review
21:17 Lyude: just saying
21:17 jadahl: :)
21:17 swick: at least on anything with a backlight
21:17 swick: OLED and mLED might behave better
21:17 Lyude: swick: actually i'm pretty sure the situation is very similar for oled
21:18 Lyude: at least I think?
21:18 Lyude: no idea about mled
21:18 swick: really? if we have the same luminance as in SDR mode?
21:19 swick: I mean obviously there will be a higher power draw when the content results in higher luminance
21:19 Lyude: swick: i have no idea, I just assume that's why those optimization modes seem to also be available on amoled
21:19 Lyude: swick: actually-i think the second thing you said is more accurate
21:20 Lyude: keep in mind i've barely look at some of this stuff and have been waiting for code to go through, so I may certainly get some details wrong :)
21:20 swick: I would really love to play with different HDR displays but no moneys
21:21 swick: also extended range in the blacks would still be HDR without higher power consumption
21:23 Lyude: swick: i meant the other way around, higher luminance would draw more power
21:23 Lyude: and iirc hdr can mean higher luminance
21:27 swick: yes, that's the "normal" case with HDR
21:27 karolherbst: hah!
21:27 karolherbst: curro, jekstrand: the bug is indeed a memory corruption thing
21:28 karolherbst: https://gist.github.com/karolherbst/67cbb02374d34535920b580188183daa
21:28 karolherbst: but that could be caused by my changes
21:30 jadahl: swick: Lyude what I mean is "hdr" on, but sdr luminance, tht's assumed to eat more power than the same luminance but without hdr mode turned on
21:33 jenatali: karolherbst: That's... a pretty deep stack
21:37 curro: karolherbst: whoa, i think i know what's going on
21:37 karolherbst: yeah.. I do a run without my patches and see if I hit it as well
21:37 karolherbst: but this explains this "something is odd" feeling I had all the time
21:37 karolherbst: we shouldn't cause stacks with 80k+ entries, but I don't think this was the issue
21:38 karolherbst: mhhh
21:38 curro: karolherbst: yeah, stack depth seems pretty normal for a recursive traversal of the event graph
21:38 karolherbst: I think libasan doesn't work anymore :D
21:38 karolherbst: jenatali: you call this deep? :D
21:38 karolherbst: wanna see a deep stack?
21:39 curro: karolherbst: i think this is a reentrancy issue with the code you added to clear the dependency list on ::fence()
21:39 karolherbst: jenatali: I just drop this here "#43650 0x0000000000417d4d in main (argc=2, argv=0x7fffffffd618) at ../test_conformance/images/kernel_read_write/main.cpp:408"
21:39 jenatali: Oof
21:39 karolherbst: curro: I removed the code and got a SIGSEGV
21:39 karolherbst: ahh
21:39 karolherbst: now asan drops
21:39 karolherbst: "SUMMARY: AddressSanitizer: stack-overflow ../src/gallium/frontends/clover/core/event.cpp:171 in clover::hard_event::wait() const" :D
21:39 curro: karolherbst: SIGSEGV due to stack overflow probably?
21:39 karolherbst: yeah
21:40 karolherbst: so mhh
21:41 curro: karolherbst: i think reentrancy issue has to do with some random event having wait() called on, which traverses its dependency list in order to wait for them, which recurses and eventually leads to a QUEUED event calling ::flush(), which causes the original event that called wait() to also get flushed and fenced, which deletes its dependency list and frees the dependencies before we're done traversing them
21:41 karolherbst: mhhhh
21:41 karolherbst: maybe
21:42 karolherbst: I think I can add an assert to check if the deps list is suddenly empty
21:43 curro: karolherbst: reentrancy issue explains why doing flush() up front fixed the issue -- then everything that was previously QUEUED gets flushed up front so no dependency lists disappear during traversal
21:43 karolherbst: jenatali: also, I have professional experience as a java backend dev, and let me say this: 350 function on the stack? happens quite often :p
21:43 karolherbst: curro: yeah.. I guess that makes sense
21:44 karolherbst: sooo...
21:44 karolherbst: how do we want to prevent the list of getting to deep? obvisouly flushing, but that doesn't clear the dep list
21:44 karolherbst: where/when do we want to clear the deps?
21:46 curro: karolherbst: how about you also change event::wait() to std::swap(deps, local_temporary_variable_holding_deps), so a subsequent ::fence() on the same event doesn't need to clear anything whenever it tgets called?
21:47 karolherbst: curro: I think the issue is that we have an iterator on deps
21:47 curro: karolherbst: and with my change you'll be iterating a local variable instead
21:47 karolherbst: ohh event::wait..
21:47 karolherbst: not hard_event::wait
21:47 karolherbst: mhhh
21:48 karolherbst: I guess
21:49 curro: karolherbst: with this suggestion implemented the dependency list of an event will be automatically cleared by wait(), but that's fine because you don't ever need to call wait() on the dependencies of an event more than once
21:50 karolherbst: yeah
21:51 karolherbst: ehhh
21:51 karolherbst: curro: event::wait is const :/
21:52 karolherbst: not sure if we can drop that
21:52 curro: karolherbst: we could but you may as well make the deps list mutable for the moment
21:53 karolherbst: how?
21:53 curro: mutable std:vector<...> deps;
21:53 karolherbst: ahh
21:55 curro: karolherbst: it seems like a legit use of mutable since wait() doesn't change the external behavior of the object even though it might be cleaning up some redundant data structures
21:59 karolherbst: yeah
22:15 karolherbst: curro: yeah, that fixed it
22:15 karolherbst: soo.. now let me run all tests
22:15 curro: karolherbst: neat :)
22:17 jekstrand: karolherbst: What fixed it?
22:18 curro: see scrollback right above
22:24 jekstrand: Making deps mutable and removing stuff in wait? That sounds like exactly what I was thinking of doing but decided against because It wasn't clean enough. :-P
22:26 curro: jekstrand: it's not the clearing of depedencies in wait() that fixes it, that's an accidental consequence of the workaround i suggested -- it's the part about doing the dependency list iteration in a local temporary that should fix the reentrancy issue we were discussing above
22:26 jekstrand: Ah
22:27 jekstrand: That makes sense.
22:30 karolherbst: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7241/diffs?commit_id=1d33b1640b5be754a0261d199d0797b35fb31eaa
22:30 gitbot: Mesa issue (Merge request) 7241 in mesa "Draft: OpenCL 1.2 image support" [Opencl, Clover, Opened]
22:30 karolherbst: for the full patch
22:30 karolherbst: although I think I can drop the deps.clear() :)
22:33 curro: karolherbst: looking pretty good. i'm betting though that the stack overflow will come back if you drop the deps.clear() in there
22:33 karolherbst: mhhh
22:33 karolherbst: ohh right, that's in fence, yeah probably
22:35 karolherbst: ahh annoying, GPU context crashed