00:00 robclark: idk there might be some weird case where it finds sqe/gmu but not zap? That could well be untested combo.. idk
01:06 karolherbst: ehhh
01:06 karolherbst: can somebody explain to me why SpvBuiltInSubgroupMaxSize exists?
01:06 karolherbst: how is it any different from SpvBuiltInSubgroupSize...
01:08 airlied: karolherbst: probably have to read the CL specs for those
01:08 karolherbst: yeah.. but...
01:08 airlied: get_sub_group_size and get_max_sub_group_size seem to correspond
01:08 karolherbst: right
01:08 airlied: then you have the fun of asking why CL does something :-P
01:08 karolherbst: but it's not quite clear to me when those functions can return different values
01:09 karolherbst: sub_group_size: "Returns the number of work-items in the subgroup.... This will be a constant value for the lifetime of the subgroup."
01:09 karolherbst: max_sub_group_size: "Returns the maximum size of a subgroup within the dispatch. This value will be invariant for a given set of dispatch dimensions and a kernel object compiled for a given device."
01:09 airlied: maybe if you have intel simd16 vs simd32?
01:10 airlied: max would be 32 and 16 would be size?
01:10 karolherbst: but different sizes within the same dispatch?
01:10 karolherbst: also.. why would the kernel care?
01:10 karolherbst: the API already provides the max size
01:11 karolherbst: I can see it's being useful if the sub group sizes within a dispatch
01:11 airlied: oh maybe "In addition, all sub-groups within a work-group will be the same size, apart from the sub-group with the maximum index which may be smaller if the size of the work-group is not evenly divisible by the size of the sub-groups "
01:11 karolherbst: but .... uhh.. what hardware needs this?
01:11 karolherbst: mhhh
01:11 karolherbst: fair point
01:11 karolherbst: not supporting it yet, but yeah...
01:12 karolherbst: I wonder what we do currently if.. well.. if the local group is like 15 threads
01:12 karolherbst: do we return 32? do we return 15?
01:13 karolherbst: but what's also confusing, that it seems gl_SubGroupSizeARB is defined like max_sub_group_size
01:14 karolherbst: I'll just use SYSTEM_VALUE_SUBGROUP_SIZE until it breaks :shrug:
01:16 karolherbst: I'm sure the CTS will tell me if I do something incorrectly
01:18 karolherbst: airlied: funky.. there is also get_enqueued_num_sub_groups....
01:19 karolherbst: who even needs all of this
01:25 gfxstrand: karolherbst: Yeah... Been throwing you stuff on Mastodon
01:25 gfxstrand: Not been paying attention to IRC today
01:27 karolherbst: fair
01:27 karolherbst: I'll deal with subgroups first anyway
01:27 gfxstrand: fair
01:30 karolherbst: this starts to become serious API work :'(
01:31 karolherbst: clGetKernelSubGroupInfo is already a mess
01:31 gfxstrand: Ugh
01:31 gfxstrand: I can imagine
01:31 karolherbst: yeah soo
01:31 karolherbst: it is for querying limits, but it also imputs the block dimension...
01:32 karolherbst: quite painful
01:32 karolherbst: I think I'll cheat my way out
01:34 karolherbst: `ERROR: get_max_subgroup_size() doesn't match result from clGetKernelSubGroupInfoKHR, 16 vs 32` :)
01:35 karolherbst: *sigh*
01:36 karolherbst: this is probably my fault
01:39 karolherbst: for a given shader in iris, how can I figure out what's the max supported subgroup size?
03:43 kode54: not sure if this is desired or not
03:43 kode54: https://gist.github.com/kode54/fc41a6bf5ebba00e3ab52e70b93dfd6a
03:43 kode54: this alteration will be needed for userspace 32-bit on 64-bit kernel to work with the existing headers, without breaking existing binaries released by Intel for 64-bit
03:45 kode54: rebuilding the newly rebased drm-xe-next kernel (whee, it's now on 6.3.0)
03:45 kode54: I'll have to rebuild my mesa too, since I accidentally aligned a purely u16 structure that didn't warrant it without breaking compatibility with 64 bit
03:46 kode54: apparently 3x __u16's will not be aligned to 64 bits or even 32 bits if there are no larger members to the structure
03:48 kode54: I found that mlankhorst 's rev 1 didn't work with intel-media-driver preliminary PR, because some handle members were expected to still be 32-bit wide
04:01 gfxstrand: Yeah, let's make sure we fix those before they become immutable uAPI.
04:01 gfxstrand: mbrost__: ^^
04:02 mbrost__: yep
04:02 gfxstrand: kode54: Just to be clear, those are because uint64_t only has a 4B alignment on 32-bit builds, right?
04:02 kode54: yes
04:02 gfxstrand: kode54: Thanks for catching that!
04:03 kode54: actually, mlankhorst caught it first, to be honest
04:03 mbrost__: We have probably about a year before the uAPI is immutable
04:03 kode54: but his attempt to fix it also rewrites a lot of the headers
04:03 mbrost__: but probably can fix this pretty quickly
04:03 kode54: and breaks compatibility with 64 bit userspace that already uses the headers
04:03 kode54: (thanks, Intel, for already releasing "release" software that implements this)
04:03 mbrost__: just gotta coordinate IGTs + UMDs + KMD
04:04 mbrost__: I'll bring this up with the team and try get this moving
04:04 airlied: what released software has it?
04:04 kode54: intel-compute-runtime implements Xe in 23.09
04:04 airlied: if any software has this stuff merged into it's master before it lands in the kernel, that's a pretty big screwup
04:05 airlied: you might end up having to burn the whole uapi down
04:05 kode54: my attempt only makes the corrections necessary to ensure 32/64 match the existing header
04:06 kode54: mlankhorst made an attempt to resize some of the members, reorder a few here and there, etc, and needed to respond to some feedback
04:06 mbrost__: afaik we are not releasing any UMDs based on Xe, we might have public branches
04:06 airlied: better check intel-compute-runtime hasn't messed up the plan
04:06 airlied: if it has and it shipping in distro, you are probably going to have to figure out a new name for the driver :-P
04:06 gfxstrand: Oh, I assume either intel-compute-runtime or intel-media-driver will mess it up.
04:07 kode54: intel-media-driver only has an unmerged "DO NOT MERGE" MR
04:07 gfxstrand: There's a part of me that's perfectly okay with them blowing up. If it's compute-runtime, we'll just tell people to use rusticl. :-P
04:07 kode54: and it doesn't even detect which driver it's using yet, it only hard codes which it thinks it's using based on an environment variable
04:07 gfxstrand: But, yes, they need to very much not do that
04:07 kode54: the media runtime one doesn't even include the xe_drm.h
04:08 airlied: gfxstrand: the problem is any distro shipping that crap, and it works with i915, then xe blows up, we have to eat the regression reports
04:08 mbrost__: i will check on this now...
04:08 airlied: if it's behind some flag or not on by default that is less worrying
04:09 gfxstrand: airlied: Yeah, I get that.
04:09 kode54: Arch isn't distributing 23.xx yet
04:09 mbrost__: probably be until the us morning though to get a response
04:09 kode54: I got them with a -bin AUR package that pulls directly from Intel's github
04:10 kode54: gonna reboot into this new kernel, and check if the compute runtime suddenly works again
04:10 kode54: (one struct I shouldn't have padded)
04:14 kode54: yup, intel-compute-runtime-bin works again
04:14 kode54: or at least doesn't crash
04:14 kode54: let's see if I can actually get it to compute some things now
04:16 kode54: yeah, nah, intel-compute-runtime hangs the engine once again
04:17 kode54: https://gist.github.com/kode54/b3b44aa3b9d4ce74f31c4234020541fc
04:26 kode54: ffs
04:27 kode54: the intel-media-driver PR even hardcodes a PCI ID for a tigerlake device
05:58 mlankhorst: airlied: I have a pull req for drm-misc-fixes only from last time that wasn't merged, with 2 patches added this week, do I just wait for rc1?
06:02 airlied: mlankhorst: yeah I can't pull that until rc1
06:02 airlied: because it requires backmerges
06:02 airlied: and I rarely feel it's that urgent
06:02 mlankhorst: yeah true, no worries
06:03 airlied: I suppose I could in theory just forward it to Linus as a separate pull outside of -next but it seems messier
06:03 mlankhorst: misc-next-fixes was empty anyhow
06:15 DavidHeidelberg[m]: anholt: Hey! Direct firmware load for qcom/a660_sqe.fw failed with error -2 the two firmwares from linux-firmware seems to missing in the image
07:19 MrCooper: Joss or somebody like him is on #freedesktop as polygon2, I don't have the power to quieten him there
09:03 daniels: MrCooper: sure you do!
09:05 dolphin: he's also on #intel-3d for that matter
09:20 mlankhorst: it's amazing how many workarounds he finds to irc
10:33 karolherbst: _why_ is this test launching a 80x7x1 block :')
14:40 jenatali: Ugh. Why is https://registry.khronos.org/vulkan/specs/1.3-extensions/man/html/VkD3D12FenceSubmitInfoKHR.html a thing?
15:35 rodrigovivi: kode54 which github do you use to get this NEO driver? just trying to understand if it is the master development branch or that that out-of-tree intel-gpgpu deliverable... okay... I don't believe that xe should be enabled in any of them anyway, but I'd like to understand better where this is currently coming from
16:51 jenatali: So I'm looking at KHR_external_memory. Is there any facility for supporting sharing on a subset of memory types? I see you can filter based on buffer/image properties, but not memory types...
17:01 bl4ckb0ne: might be a long shot, but does anybody here know about open positions (fulltime or contract) to work on linux graphics
17:03 jenatali: Ah ok, I see what's missing. When a buffer/image is created exportable/importable, it has a chained struct, which can then modify the memory requirements for that buffer/image to select an appropriate memory type
17:19 rodrigovivi: kode54: nevermind... we figured out where this build flag is coming from and have already requested them to remove it...
19:48 sima: hwentlan_, I'm a bit thrash (caught a cold) so upfront a-b: me for a patch to add a link to the uapi section pointing at the kms properties section
19:48 sima: or maybe move that to the uapi section and add a link to the property section, might be even better
19:48 sima: or ping me when you have something since I'll probably miss
19:56 tirixta: Sex in a Minecraft world? It is more than possible! Read the spellbinding tale of Justin Bieber, Mariah Carey, and an English teacher from Regina who meet up, have a threesome, and even make hot pockets! The Minecraft pigs oink with pleasure as they watch the orgy from their pigsty! Read all about it today! https://justpaste.it/MariahCareyMinecraftALHotPocket