01:18airlied: j4ni: can you pick up https://patchwork.freedesktop.org/patch/404906/
05:50orderlyunicode: So I was directed to come here for support from the Mesa readme on Gitlab. Anyone else having significant performance dips from Mesa 20.2.3?
05:52airlied: orderlyunicode: need to be a lot more speciifc about hw and workload
05:56orderlyunicode: Apologies, I forgot to mention a few things. Namely, the performance dip seems to only affect my dedicated GPU (AMD RX560x) and it seems to be just a straight performance decrease across the board. For example, even glxgears was giving me a third of the framerate of my integrated GPU.
05:59orderlyunicode: More specifically, the parts of my workload that are GPU intensive are mostly games and game development.
08:01j4ni: airlied: yeah, sorry, missed the CI results mail
08:24Sumera: Hi, I am building the kernel docs on drm-misc-next and I am getting a *LOT* of warnings. Is this expected behaviour or there might be something wrong with my system? https://paste.ubuntu.com/p/7QcJ63NwXN/
08:36emersion: Sumera: no, these are just things that need fixing
08:41MrCooper: and pre-merge CI :)
08:41MrCooper: orderlyunicode: 20.2.3 compared to which version?
09:23orderlyunicode: Presumably, 20.2.2, considering the timing of when it started and how frequently I update software
09:24orderlyunicode: Sorry for the late reply, MrCooper
09:25MrCooper: the most helpful thing would be if you could use git bisect to isolate the change between 20.2.2 & 20.2.3 which caused it
09:40orderlyunicode: Perhaps this is obvious, but I have little experience with git, would I just run git checkout for the repo and then bisect?
09:52tzimmermann: airlied, davnet, FYI there's nothing new in drm-misc-next-fixes. so no PR this week
10:56amonakov: orderlyunicode: 'git bisect' is a built-in git command, you'd start with checking out the 20.2.2 tag in the repo, verifying it's slow, then issuing 'git bisect bad' command
10:57amonakov: likewise then you can checkout the 20.2.3 tag, verify it's fast, 'git bisect good', and then git will checkout intermediate states for you
11:03MrCooper: amonakov: .3 is slow, .2 is assumed fast
11:06amonakov: oh right, of course, orderlyunicode, please swap 20.2.2 <-> 20.2.3 in my responses to you
12:46zmike: karolherbst: yeah, so that type of bitcast is illegal and vtn fails it :/
13:01pinchartl: danvet: unless I'm mistaken, drm_kms_helper_poll_fini() isn't drmm_*-managed yet. is that intentional ?
13:06karolherbst: zmike: mhh.. annoying :/
13:06zmike: karolherbst: yea
13:06karolherbst: what is it complaining about?
13:06zmike: it's a total bit size mismatch thing
13:06karolherbst: maybe cast first then?
13:06karolherbst: because then it should match
13:06zmike: yea that's not gonna work either
13:06zmike: need to be able to do something like select 3 members from an array
13:07zmike: which can't be cast with matching bitsize
13:08zmike: your ptr cast idea sounded good, but it seems like the actualy implementation doesn't account for ptrs and just directly casts the underlying type
13:09zmike: the spec is somewhat ambiguous (in my reading anyway) about whether that sort of thing is allowed
13:10karolherbst: zmike: yeah, .. right
13:10karolherbst: but I guess you want to select 3 specific elements?
13:10karolherbst: then I guess you need to do three access chains and loads, no?
13:10zmike: I want to be able to select n elements from an array
13:10zmike: and ideally I'd like to not have to do multiple access chains like that :)
13:11zmike: that's what the current implementation I'm trying to rewrite does
13:11zmike: and it's not the most readable
13:11karolherbst: mhh, in CL it would be easy, cast to vector and shuffle
13:13karolherbst: but I am still wondering why bitcast wouldn't work
13:13zmike: can't shuffle a ptr<vec> though, can you?
13:13zmike: bitcast fails at vtn_alu.c:801
13:13karolherbst: zmike: sure, you need to load first
13:14karolherbst: zmike: well.. depends on how you cast, but you need to cast from an 8 element type to an 8 element type as long as you keep the base type the same
13:14zmike: yeah, but I don't really want to load unnecessary data in case I'm running on a garbage driver that can't eliminate it
13:14karolherbst: so array -> array
13:14karolherbst: but yeah
13:14karolherbst: wouldn't work with 3
13:14karolherbst: zmike: maybe open code it in a CL kernel and compile that to spirv
13:15karolherbst: or maybe one can do it with glsl even?
13:15zmike: I don't think that'd help since it has to go in a spirv shader
13:15zmike: I'm rewriting ubo/ssbo loading in zink
13:15karolherbst: yeah.. I meant to figuring out what llvm produces and do something similiar
13:16karolherbst: but I am sure it will end up doing something stupid
13:16karolherbst: but you can do arbitrary casts in CL
13:16karolherbst: so maybe...
13:16karolherbst: sadly I don't have time to look into it until in 8 hours
13:16zmike: sure, appreciate the ideas
13:18karolherbst: you could probably also cast to a struct with internal padding...
13:18karolherbst: but that's a lot of code as you have to create the struct type
13:18karolherbst: and I am sure some glsl reason makes it not work
13:19zmike: well glsl doesn't matter in this case since I'm translating glsl -> spirv
13:19zmike: so I just have to be spirv/vulkan legal
13:19karolherbst: sure, but I meant graphics vs kernel spirv
13:20zmike: doesn't opencl in mesa still use vtn?
13:20zmike: if so then it seems odd that I'm hitting a fail on that bitcast if it's legal in cl
13:21karolherbst: well in CL you cast the pointer
13:21karolherbst: one additional level of indirecton
13:21zmike: maybe I'm casting the pointer wrong?
13:22karolherbst: don't think so
13:22karolherbst: the issue is that you kind of need a ptr of ptr
13:22karolherbst: you don't have that in glsl
13:22karolherbst: but sure, you could convert stuff around
13:22karolherbst: but I think that's also painful
13:23zmike: what are are you thinking in that sense?
13:23karolherbst: probably more work than a simply accessChain+load loop
13:24zmike: possibly not?
13:24zmike: I have a lot of weird util functions available to me
13:25karolherbst: yeah... maybe not, anyway gtg
13:49danvet: pinchartl, there's a lot that's not yet drmm-ified
13:50danvet: pinchartl, I think maybe also good to add devm_ support to _enable/disable
13:51danvet: so that drmm_.._init could call devm_.._enable
14:59MrCooper: danvet: AMDGPU_TILING_* are defined in amdgpu headers, not in drm_fourcc.h
15:01danvet: MrCooper, maybe good reason to switch over to drm_fourcc modifiers :-)
15:01danvet: but yeah for amdgpu headers probably don't want those in the main driver
15:12MrCooper: still not seeing how DRM modifiers would actually be useful for Windows
15:24jekstrand: zmike: Not with graphics SPIR-V
15:24zmike: jekstrand: :/
15:25danvet: tomba, vsyrjala I'll let you to figure out the legacy gamma story :-)
15:28tomba: danvet: vsyrjala: I'm fine with just the first patch (of the two) I sent, as that allows me to add the CTM to omapdrm. The second one definitely conflicts with what Ville has in his branch.
15:30zmike: jekstrand: does 'logical pointer' in spirv prevent doing something like creating an array of ptr<uint from access chains and then later extracting the pointers to load?
15:30zmike: getting odd unexpected validation errors
15:33vsyrjala: tomba: danvet: i don't expect to have time to think about that branch in the near future, so if you don't want to grab stuff from it then probably better ignore it for now
15:34jekstrand: zmike: Logical pointers can't do casts. That's the big thing.
15:35zmike: jekstrand: sure, but if I'm just collecting a group of ptrs into an array and extracting them then that should be legal, right?
15:38jekstrand: zmike: You have an array of pointers? That isn't allowed either
15:39zmike: jekstrand: it's not? I don't actually get validator/nir warnings from that though
15:39jekstrand: zmike: The two big rules for logical are: 1) No casts 2) No storing pointers to variables or passing them through selects or phis. All pointers have to be trivially chasable to the variable.
15:39jekstrand: zmike: Our SPIR-V parser can handle a rather advanced superset of graphics SPIR-V
15:39zmike: okay, so no pointer aliasing for logicals
15:39jekstrand: Graphics + OpenCL + stuff
15:39zmike: that...definitely complicates things
15:41jekstrand: What problem are you trying to solve?
15:41zmike: I'm working towards moving zink to a deref model for bo load/store over the current thing with explicit io
15:42zmike: because all the actual type info is lost by the time I get it, I've been using uint arrays for the bo variables in spirv
15:43zmike: and then I just load/store to the data offset
15:43zmike: but translating that to something where I can create a variable representing that offset and then separately/later do the actual load/store is proving more challenging than expected
15:44zmike: originally I wanted to just store the accesschain ptrs for the var derefs and then load them directly, but as we've now covered, that doesn't actually work for anything with >1 components
15:50zmike: when even jekstrand gives the :-/ reply I know I'm in deep
15:51jekstrand: In theory, it should be reasonable to translate GL to Vulkan SPIR-V.
15:51jekstrand: The only tricky part is if you have multiple BO arrays in GL and you want a single array in Vulkan.
15:52jekstrand: But even that should be tractable. You just have to rewrite all the bottom-level array derefs to have an offset from the first BO
15:52zmike: in theory maybe, but in practice is actually insane to try and do it through gallium due to stuff like atomic counters totally blowing up things that should be straightforward
15:53jekstrand: Yeah, none of that stuff is going to play friendly with derefs, I'm afraid.
15:53zmike: and then trying to figure out a buffer access paradigm (var decl + actual access) that is feasible
15:53zmike: but you were the one who said I should be moving to derefs hahahah
15:54zmike: okay, so maybe I need to be 🤔 about this from a different angle as just resolving the counter awfulness
15:55zmike: jekstrand: fwiw this is also in reference to our convo a long time ago re: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6273
15:55jekstrand: You really shouldn't take what I say as a message from God or anything. I say lots of dumb stuff. :P
15:55zmike: well it sounded totally reasonable back then
15:56jekstrand: I do think using derefs for buffer access is a laudible goal.
15:56jekstrand: But there's always work between here and there and, as always, the devil's in the details.
15:56zmike: hell of a devil in this case haha
15:56jekstrand: Atomic counter lowering, for instance. Maybe that pass can be modified to work with derefs?
15:56jekstrand: Maybe that's a terrible idea?
15:57zmike: I was just going to try skipping that pass since there's a pipe cap for that now
15:57zmike: the main issue with counters is just in how they're part of gallium absolutely annihilating all the nir_variable binding info
15:58zmike: which makes supporting gl_spirv impossible
16:05karolherbst: zmike: for gl_spirv isn't it easier to just adjust the actual spirv a little?
16:06zmike: karolherbst: the spirv isn't the problem, it's purely in connecting the descriptors to the bindings in the shader because the var->data.binding values get mangled
16:06zmike: so at least some small part of that should become easier to possibly resolve once I nuke counters
16:06karolherbst: but for that it seems to be easyer to have a SHADER_IR_SPIRV and support it in the driver, no?
16:07karolherbst: then you don't have to dela with any of the intermediate stuff
16:07zmike: no, unfortunately it's still gonna be a thing since gl_spirv is still a gl shader
16:07zmike: and thus needs rewriting to work in vk
16:07karolherbst: and parse the spirv a little... but maybe that's also annoying. We have also special parsing code in clover and it sucks
16:07zmike: so I just let it go through the usual compile pipeline
16:08zmike: feels real stupid to be doing spirv -> spirv conversion but here we are in 2020
16:08karolherbst: wasn't there a vk extension to accept gl spirvs? :D
16:09karolherbst: I think nvidia has one
16:09zmike: kinda doesn't matter? no matter what the vk driver does it's still going to need work done before things get to that point
16:09karolherbst: probably yes
16:10zmike: if only things could be so simple :)
16:10karolherbst: you mean one API and everybody just uses that? :p
16:10zmike: no, no, I wouldn't dare suggest such a thing
16:12karolherbst: we simply need a company like apple just doing linux desktop stuff and they kill of APIs we don't like :D
16:12zmike: they're already doing that without such incentives though
16:13zmike: sure, they're also killing off the ones we do like, but beggars can't be choosers
16:49pinchartl: danvet: I'm converting rcar-du to the managed API and I'm running in an issue. encoders are allocated with drmm_kzalloc(), after drmm_mode_config_init(). they are thus kfree()d automatically, and then drm_mode_config_init_release() is called by the resource manager, which calls drm_mode_config_cleanup(). this ends up accessing the freed encoders
16:49pinchartl: what's the right way to handle this, when you have to allocate DRM objects dynamically, not just the structure containing the drm_device ?
17:25danvet: pinchartl, are you using the patch set from philippe zabel for kms objects?
17:25danvet: those should work and avoid this issue
17:26danvet: it's unfortunately not yet merged for reasons not quite clear to me
17:26danvet: and no imx people around right now
17:26danvet: pinchartl, if you just hand roll it'll go boom, that's kinda expected :-)
18:38dcbaker[m]: pierre-eric: a5e0a2e101 is nominated for stable as a revert, but it looks like from the commit message that it shouldn't be because it's not correct without additional not nominated patches. Is that correct?
18:41pinchartl: danvet: I'm not using that, no. I'll have a look. thanks
18:42danvet: pinchartl, iirc it's pretty much ready, just somehow never landed
18:42pinchartl: "[PATCH v3 1/7] drm: add drmm_encoder_alloc()" ?
18:42pepp: dcbaker: yes, correct (= shouldn't be backported)
18:43danvet: pinchartl, yup
18:43danvet: quoting myself "Anyway I think it looks all neat."
18:43pinchartl: danvet: that would work in this specific case. but I can easily imagine a driver wanting to embed both a drm_encoder and a drm_connector in the same structure, and that won't be possible
18:43dcbaker[m]: pierre-eric: cool, marked it as de-nominated. Thanks
18:43danvet: pinchartl, yeah then you need to open code
18:44danvet: well it's not much, you just need to add a drm_add_action_or_reset
18:44danvet: instead of using the cleanup hook
18:44pinchartl: is drm_add_action_or_reset() better than a custom cleanup hook btw ?
18:45pinchartl: it requires a custom cleanup handler passed to drm_add_action_or_reset()
18:45danvet: one doesn't crash :-)
18:45pinchartl: so it's custom code in both cases
18:46pinchartl: in this case I mean kzalloc() + custom encoder cleanup hook compared to kzalloc() + drm_add_action_or_reset()
18:46danvet: yeah it's a wash for this
18:46danvet: if you need the special case
18:47danvet: otherwise use the helpers in that patch series
18:47danvet: also we probably want a patch on top that adds this explanation to the existing @cleanup kerneldoc
18:48danvet: the trouble is that right now everyone just assigns the cleanup function there and forgets about the kfree
18:48danvet: or uses devm_kzalloc
18:48danvet: so imo the ->cleanup hook has a bit Big Mistake energy :-)
18:48pinchartl: I'll start without Philipp's series as I have an actual bug in the code that causes a use-after-free and I'd like to fix that without any dependency, but I can switch to drmm_encoder_alloc() later
18:49pinchartl: the ->cleanup() hook can be implemented cleanly, but my experience is also that it's often badly implemented, and issues are not always caught during review
18:51danvet: yeah it can be, but most often kinda isnt'
18:51danvet: pinchartl, tbh, just pull that into your series
18:51danvet: or I apply to drm-misc
18:51danvet: there's no point waiting imo with merging these, I've just been waiting for an excuse
18:53ajax: jenatali: the answer to my question from yesterday about srgb appears to be dx9_1: https://docs.microsoft.com/en-us/previous-versions/ff471324(v=vs.85)
18:53jenatali: ajax: Cool, good to know
18:54jenatali: ajax: Actually, if you're going based on that, it might've been earlier - 9.1 is as far back as D3D10Level9 goes
18:55pinchartl: pH5: wanna push the series to drm-misc ? :-)
18:56pinchartl: danvet: actually
18:56pinchartl: the reason it's not in drm-misc yet may be because it hasn't received any Rb tag ?
18:56dcbaker[m]: pendingchaos: I don't know if James Park in on IRC, but you reviewed the patch. Can you take a quick look at "radv: Fix leak in radv_amdgpu_winsys_destroy()" on the staging/20.2 branch. the base is slightly different than master (namely that there is no u_rwlock). I think what I've done is correct, but could you double check?
18:56pinchartl: the last version I can see is v3 from September
18:56danvet: pinchartl, I was kind assuming imx people would r-b when it lands in that tree
18:57danvet: but never happened
18:57pinchartl: dinner time, I'll be back in a bit
18:58danvet: pinchartl, if you whack an ack or t-b onto it, I'll merge to drm-misc
18:58danvet: or ack for merging through any tree really
18:58ajax: jenatali: old enough for my purposes anyway. my context for asking is i have an experiment branch to chop off the non-shaderful drivers and see how much gets simplified away once you can assume ~gles2
18:58pendingchaos: dcbaker[m]: hakzsam reviewed that patch
19:00ajax: which also happens to be ~gl2 and ~dx9. and then gl 2.1 just adds PBOs (which gallium supports unconditionally) and sRGB textures
19:01ajax: so i was wondering whether i could assume that hardware with a windows dx9 driver could be assumed to support gl 2.1 if you tried hard enough
19:02ajax: answer seems to be yes!
19:13dcbaker[m]: pendingchaos: sorry, I knew that 😅
19:29jenatali: ajax: Yeah, at least with a WDDM driver, dunno about an XP-era driver
19:42bnieuwenhuizen: pepp: is there anything needed on the X11 side to get TMZ working. I'm getting BadAlloc with AM_DEBUg=tmz glxgears
19:43pepp: bnieuwenhuizen: yes. You need to run your compositor with disable_protected_content_check=true
20:03bnieuwenhuizen: pepp: hmm, still getting the BadAlloc even though gnome-shell has the env var ..
20:10pepp: bnieuwenhuizen: hmm. Maybe it's also required for glxgears
20:10bnieuwenhuizen: I set it for both + using gnome-shell on raw X11
20:13pepp: oh maybe that's the Xorg process that needs it? (actually I put it in my /etc/environment, so I'm not sure on the details)
20:15bnieuwenhuizen: pepp: aya that did it, thanks!
20:16pepp: bnieuwenhuizen: nice. Let me know if you can / can't reproduce the issue
20:29bnieuwenhuizen: okay I may have just caused tmz to not apply, since screenshots work
23:12airlied: jenatali, karolherbst : llvmpipe CL 3.0 (non-images) todo list :-P https://paste.centos.org/view/raw/7d0645fb
23:13jenatali: airlied: That's not nearly as bad as it could be
23:14karolherbst: math_bruteforce will be painful though
23:14airlied: math is annoying some crashes in the depths of kernel jit
23:14airlied: in the land where symbols don't exist
23:15airlied: compiler is a bit worrying
23:15karolherbst: anyway, since 15 minutes I am on PTO until the end of the year :p
23:15airlied: not sure what we are doing rong hter
23:15airlied: karolherbst: nice, so I shouldn't wait for acks to push prinf then :-)
23:15karolherbst: yeah.. well
23:15airlied: because I do not want to see printf in 2021
23:15karolherbst: I will probably have to self isolate next week when I am moving to Germany anyway
23:16airlied: ah hehe
23:16karolherbst: so I will probably have a week where I am just bored
23:17karolherbst: and still not sure when I can leave from here so I guess I will look into printf :p
23:34airlied: mareko: do we know if the sdma problems are kernel or hw or just don't care? like amdvlk exposes it and I assume must see smoe issues