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