00:52 anarsoul: imirkin: apparently there's only 2 settings for mipfilter, linear and nearest
00:52 anarsoul: so when we get TEX_MIPFILTER_NONE we have to adjust max_lod
00:53 anarsoul: as for min_lod/max_lod that's just artifact of old code... guess I need to set it to sampler->min_lod and sampler->max_lod
00:56 anarsoul: ah, it won't work since we attach only levels starting from base.u.tex.first_level
00:56 anarsoul: guess it needs to be fixed too
01:27 okias[m]: Hello guys. Do these days have DRM_VGEM any impact under llvmpipe under ARM?
01:27 okias[m]: I wonder if make sense compile this inside kernel to get increased llvmpipe performance under tegra device. kernel 5.5.0-rc5, mesa 19.3, but can use -git
01:28 okias[m]: also it's wayland only
01:28 airlied: okias[m]: nope
01:29 okias[m]: thanks, so ...as used by Mesa's software renderer for enhanced performance.... is not valid in general anymore or only for my usecase?
01:30 airlied: not sure it ever got written :)
01:31 okias[m]: ok. Any idea what could help for better llvmpipe perf? any useful trick?
01:34 airlied: okias[m]: nothing that doesn't involve profiling and coding
01:35 airlied: okias[m]: not sure how good the LLVM code produced on aarm64 is etc
01:35 okias[m]: airlied okey, I think then I'll hope someone picks up tegra gallium driver (stuck on GL 1.4, so not much useful :D )
01:35 okias[m]: this is armv7, so not even 64
01:36 airlied: oh then yeah a real gpu driver would be a much better investment
01:36 okias[m]: it's sad that there is not much bored people with RE & GPU knowledge :) ... probably because it's damn hard
01:36 airlied: old tegra is also a bit of a dead end
01:36 airlied: since they used nvidia gpu cores in newe trones
01:37 okias[m]: airlied well, I have pretty nice working tablet these days, with 5.5 kernel. Only real pain is missing 3D acceleration, since I'm using Purism Phoc/Phosh and gnome based stuff
01:38 okias[m]: rest of tablet (for it's age - Nexus 7, 2012) is pretty alive
01:38 okias[m]: general tegra support inside mainline kernels it's in very good shape
01:40 okias[m]: I was suprised that even with llvmpipe (which ugly utilize cores) it works approximatelly similiar to Android 7. When considering, that it could have accelerated 3D, so cpu gets cycles to spend on their work, it could be pretty quick
01:43 okias[m]: sorry for OT. Anyway thanks for info :) I'll at least try in next few days rebase tegra mesa tree against master. glxgears still spinning even when jumping to 19.3 branch with it,
08:22 MrCooper: airlied: might have been worth clarifying that while libGL links against X libs, it can work without an X server with EGL
10:53 tomeu: MrCooper: anholt_: are you ok with the changes in https://gitlab.freedesktop.org/mesa/mesa/merge_requests/3295 to the common CI scripts?
14:07 siro__: Hi, I found a bug in the kernel's displayport MST code and would like to fix it, but I need the displayport 1.3/1.4 spec. Can you point me to a place where I can obtain it for free?
14:08 imirkin_: afaik you have to be a member of VESA
14:08 imirkin_: some stuff *has* become open recently though ... like CTA-861-G or so
14:09 imirkin_: but i don't think the DP one is open at this point
15:58 udovdh: fwiw: the crashes are perhaps no amdgpu issue: https://bugzilla.kernel.org/show_bug.cgi?id=206191
15:58 udovdh: MrCooper, bnieuwenhuizen, Venemo
15:59 Venemo: udovdh: interesting.
16:00 MrCooper: can you capture the full output from the serial port? This is probably not going the be enough to diagnose the problem
16:10 udovdh: the setup of the terminal was still in progress
16:10 udovdh: I set it for one page of 144 lines but could not scroll back further
16:10 udovdh: The call trace is identical to my linux-kernel post
16:10 udovdh: the rest is new
16:11 udovdh: so sometimes it can continue
16:11 udovdh: and mostly it cant
16:30 udovdh: I updated the setup and SAVED it this time... so that the scrollback will be in place after powerdown/up
16:30 udovdh: one 144 line page and wordwrap enabled...
16:31 udovdh: but I guess this is getting offtopic for the topic here
19:26 seanpaul: ramaling: just noticed drm_setup_hdcp_srm(), it takes the sysfs class, but doesn't use it? seems like maybe a previous iteration used sysfs and it still has some remnants?
19:29 seanpaul: ramaling: i'm also unsure why this is managed via a global... looks like the firmware file is read every time srm is checked
19:34 mdnavare: vsyrjala: Looking at your comments on the adaptive sync limits patch, your comment suggest using if (!version_greater(...)), but if edid->version == 1 and edid->revision > 1 then it should be fine, so how did you suggest simplifying it?
19:37 mdnavare: hwentlan: Could you have Nicholas take a look at this as well: https://patchwork.freedesktop.org/patch/347704/?series=68489&rev=2
19:38 mdnavare: hwentlan: Wanted to know how this would be used insude amdgpu
19:40 agd5f_: seanpaul, HDCP 2.x requires that the srm be updated by the driver
19:40 agd5f_: in case there are new revocations
19:41 agd5f_: there's not really a good kernel interface to manage this
19:41 seanpaul: agd5f_: sure, but that doesn't require a global revocation list, right? can't you just read the firmware file in-place whenever you need it checked?
19:42 agd5f_: you need a userspace helper to save and restore the srm in the case of suspend/resume or reboot
19:43 seanpaul: am i missing some magic then? i'm specifically asking about: why srm_data needs to be a global var?
19:44 seanpaul: instead of just doing the allocation in drm_hdcp_check_ksvs_revoked()
19:45 seanpaul: seems like that would eliminate the need to have that init() function in sysfs_init() (i don't think it belongs there since there's nothing using sysfs in the srm code), and would also eliminate the need for that mutex (and serializing drm devices)
20:01 agd5f_: seanpaul, oh, that I'm not sure about. I think the thinking was that everyone would use the same srm
20:03 seanpaul: agd5f_: sorry for being vague at first. everyone using the same srm seems achieved by using the firmware file to distribute it
20:13 hwentlan: mdnavare: i image we can just call drm_get_adaptive_sync_limits in amdgpu_dm_update_freesync_caps and then change any of the amdgpu_dm_connector->min/max_vfreq uses to go to drm_display_info instead
20:18 hwentlan: agd5f_, seanpaul: i remember our psp guys didn't like the idea that every driver would use the same srm. not 100% sure why. maybe since content protection needs to be reviewed by a vendor throughout the stack and a possible interaction between two drivers might be undesirable.
20:18 hwentlan: i'd prefer a non-global SRM... but then, we're not even doing SRM check in kernel
20:22 seanpaul: hwentlan: i don't have strong feelings on whether srm should be per-device or subsystem-wide, but i am a bit concerned about that mutex allowing one drm device from blocking another from checking srm
20:23 seanpaul: s/from blocking/to block/
20:24 hwentlan: don't you need a mutex to synchronize the SRM if it's subsystem-wide?
20:24 seanpaul: hwentlan: the information in srm_data isn't shared between devices, afaict, it's completely repopulated every time someone checks revocation
20:25 seanpaul: so it'd be the same as just reading the fw file per-device
20:25 seanpaul: 1 fw file == subsystem wide srm, but doesn't necessitate devices block each other while they read it
20:27 seanpaul: worth noting that i'm just flying by, so there's probably some implementation detail i'm missing... i just saw the code and wondered if there was a reason for it
20:50 jekstrand: daniels: panfrost CI is failing for me about 50% of the time. Marge is not happy. :-(
20:52 Lyude: she looks fine to me https://en.wikipedia.org/wiki/Marge_Simpson#/media/File:Marge_Simpson.png
20:55 daniels: jekstrand: links please?
20:56 daniels: everything on https://gitlab.freedesktop.org/mesa/mesa/pipelines/ is currently happy
20:56 jekstrand: daniels: https://gitlab.freedesktop.org/jekstrand/mesa/-/jobs/1342295
20:59 daniels: jekstrand: thanks for letting me know. looks like 2 out of 3 of our Chromebooks have either a non-responsive power unit or a dead USB hub. chasing our admins to disable them now, and if that doesn't work out in a reasonable time I'll just push something to disable T860 for the meantime.
21:00 jekstrand: k
21:00 jekstrand: thanks
21:02 daniels: jekstrand: right, bad devices are currently blacklisted. really not sure why LAVA didn't pick the failures up and schedule a health check. have asked our admins to figure out why that is. thanks for letting me know!
21:03 jekstrand: daniels: yw
21:07 kisak: daniels: might be worth giving !3347 ( https://gitlab.freedesktop.org/daniel-schuermann/mesa/pipelines/96676 ) a quick check too
21:08 daniels: kisak: thanks!
21:21 kallisti5: anyone have a few seconds to review https://gitlab.freedesktop.org/mesa/mesa/merge_requests/3324 ?
21:21 kallisti5: (it's a quick one... just build fixes) I can push but need a sign-off :-)
21:33 karolherbst: anybody any idea how bootstraping the GPU (like loading firmware) can be skipped when the GPU gets runtime resumed while the process gets killed and the filesystem stuff is already teared down?
21:36 Lyude: karolherbst: maybe keep a ref to the dentry for the firmware, and release it when the application closes?
21:37 karolherbst: Lyude: well, the files get accessed while the application gets killed by the kernel
21:37 karolherbst: the fs stuff is already cleaned up at that point
21:37 Lyude: karolherbst: I mean ahead of time before the application is killed, so that you can go back to it later once the process is dying instead of trying (and failing) to look it up again
21:37 karolherbst: the kernel wants to kill all kernel tasks, but we have some stale ones which might trigger the GPU to get woken up
21:37 Lyude: although I'm not sure how the firmware helpers in the kernel work
21:38 karolherbst: Lyude: the fs is gone, so all dentries should be stale, no?
21:39 Lyude: karolherbst: dunno :S, didn't think a dentry could go stale
21:39 karolherbst: Lyude: https://elixir.bootlin.com/linux/v5.5-rc6/source/kernel/exit.c#L802 is where the fun starts
21:39 karolherbst: exit_files and exit_fs being called before kind of gives me the feeling you don't want to access any files anymore
21:39 karolherbst: exit_mm a few lines above as well
21:40 karolherbst: but that might be fine anyway
21:44 daniels: jekstrand: i cancelled https://gitlab.freedesktop.org/mesa/mesa/merge_requests/3366 as you're about to lose a race to https://gitlab.freedesktop.org/mesa/mesa/merge_requests/3363
21:44 daniels: (i assigned them both at the same time, but marge picked the latter first)
21:45 daniels: (cancelled ... the CI pipeline of ...)
21:54 jhli: Someone mind merging this getfb2 patch? https://patchwork.freedesktop.org/patch/345498/
21:54 jhli: got reviewed, I just don't have commit access
22:06 agd5f_: karolherbst, cache the fw in the driver?
22:06 karolherbst: agd5f_: yeah.. that's probably the best idea, but I think we would just need to load all fw when the driver gets loaded and just use that
22:07 karolherbst: but I really don't know how the firmware API works ..
22:18 agd5f_: karolherbst, if you call request_fw(), IIRC, the kernel caches a copy for you
22:18 karolherbst: yeah... I just found that
22:18 karolherbst: but.. it seems like we don't do that
22:18 agd5f_: you only need to call it again if you've called release_fw()
22:19 karolherbst: yeah.. I think I need to read some code
22:22 karolherbst: okay... found the problem
22:23 karolherbst: we just call release_fw immediately after loading the firmware
22:26 daniels: if anyone's wondering why CI throughput is so bad currently: four people pushed 6 new branches between them, nearly simultaneously. some were based on top of the just-merged MR to bump the ARM kernel version; rebuilding kernel/deqp/etc takes ages. there should be 3-5 Panfrost T860 devices but right now there's only one. and the kernel just merged a change which makes boot hard-hang, so there's a lot of waiting.
22:27 anarsoul: ouch
22:27 imirkin_: aka "the perfect storm"?
22:28 daniels: well, we haven't (yet) been gifted an inexplicably slow network route, so that's something
22:28 imirkin_: something to look forward to tomorrow then
22:29 daniels: (that being said, we are currently in an extended argument with our Cambridge ISP about why an inability to get more than 1.2MB/sec throughput from Google is very definitely their problem, as opposed to Google deciding based on a hash of the source IP to send them down a really really slow route, which is a novel contention)
22:31 anarsoul: tomeu: btw thanks for updating kernel in lava lab, looks like it fixed gpu error recovery issues on lima
22:32 anholt_:wishes lava lab could update rpi firmwares, would love to do vc4 testing.
22:38 daniels: anholt_: assume that requires writing to an SD card?
22:38 anholt_: unless you're using the firmware's netbooting support to load your firmware and u-boot
22:38 daniels: tomeu: i've just realised that the lava container+build jobs are cross-compiling from x86. given that we can really easily add a fair bit more ARM build capacity, it would be good to try moving those back to aarch64-native and seeing what the performance is like.
22:38 daniels: anholt_: ooh, yes please
22:39 anholt_:did all the pi3 work cardless
22:41 daniels: +++++ on fdno CI availability btw, they've been really quite responsive recently
22:42 anholt_: daniels: we're working on getting even better! there's a big old rack full of a setup that we're going to use to hopefully do lava db410c, db820c, and more chezas than before (so we can start testing vulkan)
22:44 daniels: \o/ \o/
22:44 daniels: tbf it seems at this point like piglit is mostly the limiting factor for throughput anyway, based on unscientific eyeball sampling
22:44 daniels: (apart from today where the limiting factor is everything all at once)
22:45 anholt_: I keep hoping that gitlab will sort out their kubernetes, and I'll just turn on dedicated mesa x86 capacity again
22:46 anholt_: also, I think nir-to-tgsi might cut our softpipe runs a bunch :)
22:47 daniels: \o/
22:47 daniels: anything up your sleeve for piglit-quick_gl?
22:47 daniels: somewhat of a misnomer that one
22:47 daniels: (or does piglit run on softpipe rather than llvmpipe?)
22:47 anholt_: I think we're running the piglit on llvmpipe only currently
22:48 anholt_: haven't looked into perf there. we should probably have our piglit runs be doing a report at the end of the slowest subtests
22:48 anholt_: so we can go fix or ban things
22:49 daniels: there, looks like the bad performance bubble has passed
23:03 daniels: yeah, <13min end to end (with piglit-quick_gl again the slowpoke) seems pretty reasonable
23:29 mdnavare: hwentlan: yes we could call that in amdgpu_dm_update_freesync_caps but then j4ni was also suggesting making it static because it gets called from drm_add_edid_modes() where it will populate the adaptive sync info into the drm display info, is that something that gets called in amdgpu on conn_init() then we can avoid explicitly calling drm_get_adaptive_sync_limits from amdgpu_dm_update_freesync_caps
23:45 daniels: anholt_: is wales on the other end of a 14.4k modem?