02:58robclark: imirkin_: krh was mostly considering pre-computing derived uniforms, and not specialisation like flow control.. although in some cases that might be an interesting idea
03:00robclark: so same shader (variant) would be used in all cases, but we'd compute the result of opcodes where all the src are either const or uniform (and repeat that iteratively until !progress)
06:38dolphin: airlied, danvet: hmm, I definitely sent both dinf and dif for 5.5, every week checking that previous week got pulled
07:29tomeu: anholt_: I spent some time on this once, but the interaction between the escaping in yaml and how lava parses the resulting string made it non-trivial
07:29tomeu: then I lose interest
08:06airlied: dolphin: was this the one that had the fixes? https://patchwork.freedesktop.org/patch/350273/
08:10airlied: nope doesnt habe the ickle patches
09:20danvet: tomba, jyri around on irc?
09:26tomba: danvet: yes
09:28danvet: tomba, nick?
09:29tomba: danvet: oh sorry, I thought you asked if either of us was here =) let me see. at least he's in TI irc.
09:29danvet: tomba, I just think might be easier to discuss this here quickly than lots of mails on dri-devel
09:30tomba: he doesn't seem to be on dri-devel, but I pinged him on internal irc. probably he'll join soon.
09:32tomba: as for the patch, the requirement is not to do plane commits in particular order. it's that the x/y/z pos registers are not in plane's register block, but in crtc's. and when we change a z pos of a plane, we more or less have to go through all the active planes, and adjust the crtc registers which manage the zpos.
09:32danvet: in that case, commit those from the crtc function
09:32danvet: with an interator does loops the right way
09:33j4ni: danvet: I ended up rebuilding dinf on top of drm-next anyway per your recommendation
09:33danvet: but this should happen already
09:33tomba: yes, I think that's what the patch does. but the problem Jyri had was that the state didn't have the un-changed active planes.
09:33j4ni: danvet: I'll send a pull request today
09:34danvet: tomba, is that register block per crtc
09:34tomba: the drm_atomic_add_affected_planes() helped there
09:34danvet: or across all crtc?
09:34tomba: danvet: it's per crtc
09:34danvet: tomba, atomic helpers already call that for you
09:34tomba: danvet: then I'm confused. you say that the state that crtc commit gets should contain all planes?
09:34danvet: only on modeset :-)
09:35danvet: so yeah add the add_affected_planes call when any zpos changes and you should be good
09:36tomba: ok. Jyri is working on a new revision, where he'll call add_affected_planes after the normal crtc & plane atomic check, so that the unchanged planes won't hit plane check again.
09:46danvet: tagr, did the drm_debugfs_remove_files removal from tegra get anywhere?
09:50danvet: agd5f, hwentlan what's the purpose of amdgpu_debugfs_add_files?
09:50danvet: seems a bit useless
14:03agd5f: danvet, remnant from radeon. Just a wrapper for letting other components in the driver add debugfs files
14:20MrCooper: anholt_: any idea why we're suddenly getting flakes all over the place in test-softpipe-gles31 jobs?
14:21MrCooper: I suspect there might have been some kind of memory corruption regression
15:03danvet: agd5f, yeah noticed that with more reading further down in the git grep list :-)
16:04MrCooper: kazlaus_ hwentlan: am I reading DC code correctly that it returns -EINVAL on an attempt to enable the HW cursor while no other plane is enabled?
16:22kazlaus: so the old behavior was to actually allow those commits to go through
16:22kazlaus: but the screen would be black because the hardware doesn't actually support that
16:23kazlaus: I think that actually caused a regression at some point in some userspace because they were checking the return code and they bailed out after getting that
16:23kazlaus: but I forgot to revert that back to the expected (incorrect behavior)
16:25MrCooper: yeah, I think I'm hitting that with mutter
16:26kazlaus: I'll go and make the patch now before I forget this time
16:26kazlaus: I think the issue was originally reported with vive headsets not turning off
16:26MrCooper: well, could there be a better solution maybe?
16:27kazlaus: we'd have to have a framebuffer allocated from driver
16:27MrCooper: the error does make sense for atomic UAPI, just maybe not for legacy drmModeSetCursor(2)
16:27MrCooper: so maybe the code converting between them could handle it
16:28MrCooper: e.g. by only actually enabling the cursor together with other planes
16:28kazlaus: hardware doesn't actually have cursor planes so enabling and setting up a fake pipe for a cursor is a little too messy and not really hw cursor anyway
16:29kazlaus: I think it's a regression either way since userspace didn't expect that to error out
16:29kazlaus: and it broke previously working behavior
16:30MrCooper: is there any such userspace using atomic UAPI?
16:30MrCooper: pretending to atomic UAPI users that the cursor is on when it's not seems wrong to me
16:30kazlaus: don't think so
16:30kazlaus: yeah that's why i had added it in the first place
16:31MrCooper: right, so the atomic & legacy UAPI cases should ideally be handled separately
17:24MrCooper: kazlaus: is there an issue about it?
18:17ajax: MrCooper: can you think of a reasonable way to make a triggered CI run update one of the docker images?
18:18ajax: like, commit to piglit prompts mesa to rebuild its stuff
18:20hakzsam: dcbaker: https://gitlab.freedesktop.org/mesa/mesa/merge_requests/3793
18:20gitbot: Mesa issue (Merge request) 3793 in mesa "docs/new_features: empty the feature list for the 20.1 cycle" [Docs, Opened]
18:30hakzsam: fun things, can't merge with [skip ci] https://gitlab.freedesktop.org/mesa/mesa/merge_requests/3793 ?
18:30gitbot: Mesa issue (Merge request) 3793 in mesa "docs/new_features: empty the feature list for the 20.1 cycle" [Docs, Opened]
19:05anholt_: MrCooper: nope, haven't looked into that at all
20:55maccraft: > https://www.phoronix.com/scan.php?page=news_item&px=Mesa-2020-PGO-LTO-Builds
20:55maccraft: does this mean muh games be faster?
21:02kisak: maccraft: https://lists.freedesktop.org/archives/mesa-dev/2020-February/224104.html
21:02maccraft: kisak: thank you
22:08Lyude: seanpaul: :s. so, -that- was the real reason amd patched that
22:08Lyude: i need to apply more scrutiny to their fixes
22:08Lyude: I will try to review your patches today/tommorrow
22:10seanpaul: Lyude: yeah.. it works but we already have the tx slots for outgoing msgs, so it's not too much extra to handle the replies
22:10Lyude: mhm, and that's what we probably should have been doing from the start anyway
22:11seanpaul: probably. it's tricky, and only noticeable if you're doing a bunch of edid reads
22:36Manoa: anyone know if it is possible to do supersampling with mesa ?
22:37imirkin_: seems like something st/mesa could implement for all drivers, but there is no such implementation afaik
22:39Manoa: it must be in the driver eh ? I guess not possible to do from other places like force custom Xorg desktop resolutions etc.. ?
22:40Manoa: I read somewhere someone tryed something like this it looked verry bad :x
22:42HdkR: When you are running a higher virtual resolution does it have a decent downsampling filter?
22:43Manoa: yhe, yhe that was it, that the problem, it used nearest so it look verry bad because of that :x
22:43HdkR: Thats one of the things that you need for decent super sampling like that :)
22:45imirkin_: well, usually super-sampling is a driver trick used to achieve e.g. 32x aa when the hw only supports 8x msaa
22:45imirkin_: so it just renders fat 2x2 pixel things
22:46imirkin_: and the "downsampling" becomes trivial since it's just a special case of msaa resolve
22:51Lyude: mripard/mlankhorst: Is it possible for us to get drm-misc-next-fixes merged into drm-misc-next?
23:09daniels: ajax: pass a variable to the pipeline when you trigger it
23:22cmarcelo: curro: dcbaker: R-b'ed.