11:55mlankhorst: danvet/airlied: so far I've never been able to fast-forward drm-misc-fixes this cycle, should I rebase, backmerge or just let it be since nobody complains?
12:17mairacanal: display folks, i'm having a problem when using non-blocking commits that I cannot guarantee that plane->state->fb == state->fb will be true for both prepare_fb and cleanup_fb. Sometimes, plane->state->fb == state->fb is true for prepare_fb (then I don't increase the refcount) and plane->state->fb == state->fb is false for cleanup_fb (then I
12:17mairacanal: decrease refcount). I was wondering: this driver should guarantee this condition or it is really something we cannot guarantee?
12:18emersion: mairacanal: maybe cleanup_fb runs after plane->state->fb has been updated to the new value?
12:19vsyrjala: you should not consult plane->state. get the old/new state from the commit
12:19emersion: right
12:20emersion: but tbh not sure this check is really needed? i'd just inc/dec the refcount always
12:20pq: conditional reffing sounds... strange
12:21mairacanal: "but tbh not sure this check is really needed?" -> yeah, it works just fine which it
12:21mairacanal: i was thinking about just removing this check, but I don't really know how to justify such a change
12:22pq: I can think of a few suggestions: the old code was a) more complicated than necessary, b) fragile, c) inconsistent
12:23pq: maybe even buggy, if it causes problems?
12:23emersion: mairacanal: i think what ville said should be enough
12:23emersion: but ideally that would be documented somewhere
12:23emersion: can't find where though
12:24emersion: vsyrjala: is there a place where this is spelled out?
12:26javierm: emersion: I also couldn't find in the docs, I remember adding 30b1a0797e0b ("drm/ssd130x: Use drm_atomic_get_new_plane_state()") but only because vsyrjala pointed out to me as well
12:28javierm: btw, dri-devel ML is still down right? Or am I the only one who isn't getting emails from the list?
12:30vsyrjala: i'm not sure what's spelled out in the docs. i think the get_existing_state() stuff at least is marked deprecated. but sadly seems to be lots of users left, probably equally many doing foo->state as well
12:32javierm: a patch for the docs and a gpu/todo.rst entry to fix the existing users would be nice
15:27sima: mlankhorst, yeah -rc1 is a bit old, but imo it's more important for -next since there's a lot more patches there and so higher chances for unbisectable regression
15:28sima: I guess if you want to rolling forward once just to stay in sync after a month should be ok imo, even if there's not a direct reason
15:28sima: i.e. imo backmerging -rc6 is ok if you're on -rc1 still
17:02karolherbst: jenatali: was there something I'd had to consider when lowering huge dispatches into various smaller ones?
17:02jenatali: karolherbst: Yeah, you need to add offsets for the workgroup id
17:03jenatali: Otherwise each dispatch will re-number those starting from 0
17:03karolherbst: okay.. so with API offsets they always start at 0, but when I do set it internally to lower them, I have to account for them not starting at 0 in later dispatches
17:03karolherbst: that makes sense I suppose
17:04karolherbst: and I guess same for the global id
17:05jenatali: karolherbst: Global ID is computed based on the local one
17:05karolherbst: ehh wait
17:05karolherbst: yeah..
17:05karolherbst: so
17:05karolherbst: `global_work_offset` simply impacts the global ID of threads
17:05jenatali: The global offsets are only needed to reflect the global offset functionality at the API
17:06karolherbst: okay.. yeah, so the workgroup_id is the oddball here
17:06jenatali: Yep
17:06karolherbst: I'll probably do shader variants for this and will also optimize the offsets == 0 case while at it I guess :D
17:07karolherbst: I wonder if I want to precompile the offset shader and lazy compile the lowered one or just lazy compile them both...
17:07karolherbst: mhh
17:07jenatali: Yep, I do shader variants and optimize the offsets == 0 case as well
17:08jenatali: I do both lazily right now, but that's mainly just because the local group size also needs to be part of my variant key and I can't even make a guess at that until enqueue time
17:08karolherbst: so in the worst case there are 4 variants, but like offsets == 0 and small enough grids are like 99.9% of the cases...
17:08karolherbst: well..
17:08karolherbst: on the v3d driver I need huge grids lowered as the hardware has 16 bit limits on the grid :')
17:09jenatali: Yeah D3D has that limit as well
17:09karolherbst: I think I can lazy compile all variants, as I don't see it would impact anyway
17:09karolherbst: while the GPU executes the main variant, the CPU can compile the others...
17:10karolherbst: the only case which might make sense to compile ahead of time might be the api offset one but uhh...
17:10karolherbst: whatever
17:11karolherbst: jenatali: I need to set `has_base_workgroup_id` to true and go from there, right?
17:11jenatali: Yep
17:12karolherbst: and `has_cs_global_id` needs to be false?
17:12karolherbst: or true?
17:12consolers: on wayland i was trying to use mpv --background=0/0/0/0 --alpha=yes to have a transparent background, and it works but when the background is white #ffffff, i.e. 1/1/1/0 (last number is the alpha) the whole thing becomes opaque. this is reported to work correctly with nvidia
17:13jenatali: karolherbst: Only needs to be true if the API sets it to true IIRC
17:13consolers: but I get the same sort of behaviour in xlib, which is also repeatwed here https://stackoverflow.com/questions/39906128/how-to-create-semi-transparent-white-window-in-xlib --- if the background is white, it becomes opaque
17:13karolherbst: what API?
17:13jenatali: Wait, that's just an unrelated thing, isn't it?
17:13karolherbst: yeah..
17:13karolherbst: I'm asking because there is this pattern in lower_system_values: has_base_workgroup_id || !has_cs_global_id
17:14karolherbst: but I think I need has_cs_global_id to be true, and then drivers will lower it themselves if needed
17:15jenatali: karolherbst: It's unrelated
17:15consolers: is this a bug in xorg or mesa or what layer
17:15jenatali: If you set that you're using local offsets, then the global ID is always computed from local IDs
17:15jenatali: Otherwise the has_cs_global_id not determines whether that happens
17:15karolherbst: you mean if I don't set it
17:16karolherbst: if I keep has_cs_global_id false, then setting has_base_workgroup_id to true would enable the global_invocation_id/index lowering
17:16karolherbst: if I read the code correctly
17:16jenatali: It's an or - when local ID offsets are used, it doesn't matter what that field is
17:16consolers: or intel
17:17karolherbst: jenatali: ohh.. uhhh.. that's bad tho
17:17jenatali: Why?
17:17karolherbst: why would I want that lowering?
17:17jenatali: Because when you run your second dispatch, and use a workgroup ID offset, then you want the global ID to automatically also be offset
17:18karolherbst: but that already happens via has_base_global_invocation_id, no?
17:18jenatali: I guess you could add the global offsets on the CPU side, sure
17:18jenatali: It seemed simpler to just forward through the global offsets from the CL API to that sysval, and then when using local offsets you don't need to touch the global ones again
17:19karolherbst: yeah.. I was thinking of just using the API offsets + fixing the workgroup_id
17:19jenatali: The kernel just re-computes them
17:20karolherbst: the thing is, that I kinda want drivers to use nir_intrinsic_load_global_invocation_id_zero_base when they have it
17:20karolherbst: so lowering that unconditionally kinda sounds wrong
17:20jenatali: Yeah, that's what I do too (SV_DispatchThreadID), unless you're lowering huge groups
17:20karolherbst: I see
17:22karolherbst: I think just setting base_global_id and base_workgroup_id is a bit simpler from my perspective here, so I still let drivers do as they please. I might have to look at some of the codegen, but I might also want to set `has_cs_global_id` regardless of the lowering already...
17:22karolherbst: mhh...
17:22jenatali: If you want to change the semantics there to require the dispatcher to supply local offsets + global offsets, instead of just local and letting the global be computed, I can accommodate that but it is a breaking change
17:24karolherbst: I think I'll figure out first how the nir looks like and see what I'll think would be the best here, but I think for some drivers changing the semantics might allow for better code.
17:24karolherbst: I'll have to see
17:25jenatali: I wasn't terribly worried about the codegen for the case of huge dispatches
17:25karolherbst: yeah.. but I'm hitting it with the CTS allone on v3d
17:25karolherbst: 256 * 65535 is the max thread count on 1D there
17:26karolherbst: so I'm constantly hitting it
17:28jenatali: Oh, D3D's is at least 1024 * 64K
17:30karolherbst: also.. I currently limit to 32 max threads $because_driver_limitations
17:30karolherbst: so 32 * 65535 :)
17:31karolherbst: v3d recompiles shaders based on bound textures/samplers/images, so that's kinda pain
17:31jenatali: Oh well that'll do it...
17:35jenatali: karolherbst: Anyway I'm open to changes here, just let me know if you think they're necessary
17:35karolherbst: yeah, thanks :)
17:40karolherbst: jenatali: btw.. do you know what applications use SPIR (not SPIR-V)? I might be willing to wire it up if it's important enough (even if only through wine)
17:40jenatali: karolherbst: No idea
17:41jenatali: I hooked up the compiler side of it but haven't hooked it into the runtime yet
17:41karolherbst: ohh
17:41karolherbst: I kinda thought you had a real reason to do it
17:52jenatali: Nah, just while I was in the area I exposed the methods to start with LLVM IR
17:56karolherbst: I see...
18:38karolherbst: jenatali: btw.. any reason for `clc_compile_c_to_spir` to still exist? Could nuke that part at least I think...
18:39jenatali: karolherbst: It's 12 lines of code. Doesn't seem that bad to me to keep?
18:39jenatali: Oh I guess the helper's a bit more too
18:39jenatali:shrugs
23:07jenatali: Is enunes still the right contact for lima runners? https://gitlab.freedesktop.org/mesa/mesa/-/jobs/52910034 seems busted
23:09jenatali: Thanks!