00:06 airlied: karolherbst, jekstrand : do we have a pass that could convert direct array access to a global array into a load const
00:06 airlied: it seems like the llvm backend does that at least for some tests
00:22 karolherbst: airlied: we have that already
00:23 karolherbst: you mean for mem_constant, right?
00:23 karolherbst: it's part of constant_folding
00:23 airlied: hmm doesn't seem to be wokring for the test I'm looking at
00:23 karolherbst: let me find the code
00:23 karolherbst: airlied: https://gitlab.freedesktop.org/mesa/mesa/-/blob/master/src/compiler/nir/nir_opt_constant_folding.c#L214
00:23 airlied: the test just does out[x] = arr[1];
00:24 karolherbst: const_value_for_deref tries to follow the deref chain up to the variable
00:24 karolherbst: ohh wait..
00:24 karolherbst: is that "on stack" constant?
00:24 hanetzer: damn, SneakySnake is gone
00:24 karolherbst: wait.. shouldn't matter
00:24 karolherbst: airlied: anyway, check why const_value_for_deref doesn't find it
00:28 airlied: karolherbst: we don't call constant folding early enough :-)
00:29 karolherbst: ahh
00:29 karolherbst: I guess we should fix that then
00:29 airlied: probably need to call it before lower_mem_constant_vars
00:29 karolherbst: yeah
00:30 karolherbst:totally forgot to add the pass
00:37 airlied: karolherbst: want me to post a qucik MR so you can review it?
00:38 karolherbst: yeah, although I guess it's fine, might give it some test runs tomorrow then
00:38 karolherbst: but I already tested with it enabled at some point
00:39 airlied: CI should catch anytnhing too stupid
00:39 karolherbst: hopefully
00:40 airlied: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7209
00:41 airlied: though it doesn't fix my broken test, which means I was probably looking in wrong place :-P
00:51 karolherbst: probably :p
00:52 karolherbst: airlied: anyway, mind testing a look at the image stuff? https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7069
00:52 karolherbst: I think it's good enough and the fails are all stupid
00:52 karolherbst: mostly handling of the image intrinsics
00:52 karolherbst: and I wanted to handle them the proper way inside clover
00:52 karolherbst: though not sure why "program/execute/sampler" crashed again
00:53 karolherbst: anyway.. need reviews for that MR
01:06 airlied: hmm I think my bug is global bindings getting mixed up somewhere
01:18 karolherbst: airlied: I actually don't think that llvmpipe should be fixed.. rather clover shouldn't behave that differently from st/mesa. The sampler patch I took because it kind of makes sense to allow that, but mhhh. I want to get rid of the unbinding in clover anyway and maybe we should just do that?
01:18 karolherbst: would allow us to drop this llvmpipe patch
01:20 karolherbst: ehm.. wait
01:20 karolherbst: that's for the sampler views, not images ...
01:36 airlied: karolherbst: I'm, not sure how well define the interface is from st/mesa
01:36 airlied: esp wrt what is lowered etc
02:04 airlied: karolherbst: so when constant data gets lowered it gets added to the kernel arguments
02:04 airlied: and later the global invoc id offsets get added
02:04 airlied: we then lower all the constant data but it stays in the arguments list
02:05 airlied: hmm actually maybe this is a backend bug
02:07 airlied: bleh recreating the kernel args is messy in the backend
03:41 jekstrand: airlied: We need to run optimizations in clover
03:41 jekstrand: airlied: I don't know if that means writing an opt loop for clover or tying into the back-end.
07:25 airlied: EdB_: uggh the rocm get_num_groups does an integer divide, I assume no CL apps ever use that
09:23 ivyl: I am trying to implement convicing stubs of AMD Display Library for Wine/Proton. Is there a way to query memory bandwidth of an AMD GPU? Is there an easy way to distinguish APU vs dGPU programatically?
09:26 emersion: ivyl: for the iGPU/dGPU, at least Vulkan has this info, so could look into the radv impl
09:26 emersion: https://www.khronos.org/registry/vulkan/specs/1.2-extensions/man/html/VkPhysicalDeviceType.html
09:26 emersion:thinks it may work with a big list of PCI IDs…
09:27 ivyl: I think so as well. Same with the memory bandwith - my guess is that the .dll has a lookup table for that :D
09:30 emersion:discovers https://vulkan.gpuinfo.org/
09:41 ivyl: DRM_AMDGPU_INFO ioctl with AMDGPU_INFO_DEV_INFO and checking dev_info.ids_flags & AMDGPU_IDS_FLAGS_FUSION
09:43 emersion: nice
09:43 emersion: "kernel does the work"
09:45 ivyl: yep, I have to check what's the wined3d vulkan-based adapter implementation state - that would save me a lot of hassle
09:57 austriancoder: out of interest: what are the minimum hw requirements for vulkan?
09:59 HdkR: compute is usually cited
09:59 Venemo: austriancoder: we (RADV) support Vulkan on any GCN/RDNA GPU
10:00 HdkR: I believe images and SSBOs are another hard requirement for some hardware?
10:01 Venemo: ivyl: you can check if it has dedicated VRAM or not. that's what we do, for example here: https://gitlab.freedesktop.org/mesa/mesa/-/commit/bf0c82b7f8cd8acece2adf63a32590711015864d
10:02 austriancoder: Venemo: I am asking more in the direction HdkR is answering. what features does a GPU need to support in order to be able to use vulkan without any software fallbacks
10:02 austriancoder: HdkR: that looks like a nice start of features...
10:02 HdkR: Could probably just look up all the ES 3.1 features since I think that is what the baseline was
10:03 austriancoder: maybe the spec has some notes about it
10:03 austriancoder: HdkR: okay
10:04 ivyl: Venemo: thanks, I've found it already and even figured out how to get that from kernel (see the line about AMDGPU_INFO_DEV_INFO)
10:05 Venemo: ah okay nice
10:09 Venemo: austriancoder: https://people.freedesktop.org/~cbrill/dri-log/?channel=radeon&date=2020-06-24 -> discussion starts at 15:49 in the log, maybe this is useful to you
10:10 HdkR: I guess ideal would be a list of features and roughly equivalent GL extensions would be the best. Maybe someone could whip one up some time :P
10:54 airlied: austriancoder: per process virtual memory helps a lot
10:56 airlied: might be possible to do vulkan without it, but can be messy depending on hq
10:56 airlied: hw
12:50 tzimmermann: sravn, i now implemented fb_read/fb_write completely without fbdev functions. it's maybe better not to add your previous r-b to the patch. would you take another looks at the change?
14:06 DPA: mxsfb does always scans out the whole screen, even if only a part of it changed, right?
14:30 danvet_: agd5f, just looked at amdgpu modparams for reasons, and there's a pile that seem unused?
14:30 danvet_: looks a bit like maybe missing #ifdef in the internal tree for internal features
14:30 danvet_: like emu_mode ...
14:47 jekstrand: Hey, look at all those new files in src/broadcom/vulkan! Woo!
15:57 danvet_: mripard, just pushed 2 font fixes to drm-misc-next-fixes
15:57 danvet_: merge conflict oversight, would be good to get that in next week before -rc1
15:57 danvet_: airlied, ^^
16:00 ajax: eric_engestrom: mind casting an eye over !6919 ?
16:00 ajax: or anyone else sufficiently interested in EGL
16:12 sravn: tzimmermann: sounds good! Assume they are on dri-devel so will take a look tonight
16:13 sravn: mripard, airlied - I think Guido has a few fixes too, dunno if they are pushed yet
16:18 sravn: tzimmermann: Nothing on dri-devel yet?
16:21 tzimmermann: sravn, i want to do some testing and send them out soonish
16:21 tzimmermann: thanks!
16:29 sravn: tzimmermann: np
17:34 ajax: as of like ten seconds ago, marge has committed 8306 patches
17:35 ajax: which is more than the number of patches _authored_ by any one person not named brian paul
17:39 HdkR: Marge grows more and more unstoppable every day
17:42 ajax: with 11286 patches committed in 2020 so far, we're on pace for around 13500 by the end of the year, which would mean over 10% of the commits to mesa happened in 2020 alone
17:43 ajax: gitlab seems to be a major productivity improvement
17:47 AndrewR: ajax, or people prefere smaller patches now ....
17:47 ajax: ... not entirely fair, that's just counting since the earliest commit git knows about, which is 1998, but the project started in 9
17:47 ajax: 3
17:48 HdkR: Also typical correlation != causation warning :D
17:52 ajax: cvs->git migration was 2006 (wow, that long ago). zero years before 2007 had more than 2001 commits. every year since (2008 +) has had at lest 4000.
17:53 ajax: so the "small patch" trend probably started long before gitlab
17:54 bnieuwenhuizen: ajax: I think slowly there also have been more people
17:54 ajax: yeah
17:54 ajax: i should do more detailed stats sometime, i'm sure there's some interesting conclusions to be had
17:54 bnieuwenhuizen: like with the mobile drivers and vulkan and collabora+igalia
17:55 karolherbst: ajax: well, as I see it, gitlab doesn't really resolves technical issues, but it just makes tracking and talking about changes much easier. And it's way easier for new contributors to get noticed
17:55 karolherbst: any numbers on new contributors btw?
17:55 karolherbst: or patches form small contributors generally
17:56 ajax: i can probably come up with some, yeah. have to scoot to a meeting in a minute though
17:59 macromorgan: hate to bug you guys, but has anyone had success getting Panfrost working with Android?
18:00 karolherbst: macromorgan: maybe somebody in #panfrost knows more?
18:03 macromorgan: good idea, I didn't know they had a separate channel, thank you.
19:49 agd5f: danvet_, I think mostly leftovers from when we forked from radeon
20:07 danvet_: agd5f, doesn't seem to be the same ones
20:07 danvet_: anyway doesn't hurt, just noticed