ChanServ changed the topic of #dri-devel to: <ajax> nothing involved with X should ever be unable to find a bar
<robclark>
idk there might be some weird case where it finds sqe/gmu but not zap? That could well be untested combo.. idk
mbrost__ has quit [Ping timeout: 480 seconds]
mbrost__ has joined #dri-devel
Kayden has joined #dri-devel
sukrutb_ has joined #dri-devel
sukrutb has quit [Ping timeout: 480 seconds]
Haaninjo has quit [Quit: Ex-Chat]
Zopolis4 has quit [Quit: Connection closed for inactivity]
columbarius has joined #dri-devel
co1umbarius has quit [Ping timeout: 480 seconds]
jdavies has joined #dri-devel
jdavies is now known as Guest540
jdavies_ has quit [Remote host closed the connection]
<karolherbst>
ehhh
<karolherbst>
can somebody explain to me why SpvBuiltInSubgroupMaxSize exists?
<karolherbst>
how is it any different from SpvBuiltInSubgroupSize...
yuq825 has joined #dri-devel
<airlied>
karolherbst: probably have to read the CL specs for those
<karolherbst>
yeah.. but...
<airlied>
get_sub_group_size and get_max_sub_group_size seem to correspond
<karolherbst>
right
<airlied>
then you have the fun of asking why CL does something :-P
<karolherbst>
but it's not quite clear to me when those functions can return different values
<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."
<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."
<airlied>
maybe if you have intel simd16 vs simd32?
<airlied>
max would be 32 and 16 would be size?
<karolherbst>
but different sizes within the same dispatch?
<karolherbst>
also.. why would the kernel care?
<karolherbst>
the API already provides the max size
ngcortes has quit [Read error: Connection reset by peer]
<karolherbst>
I can see it's being useful if the sub group sizes within a dispatch
<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 "
<karolherbst>
but .... uhh.. what hardware needs this?
<karolherbst>
mhhh
<karolherbst>
fair point
<karolherbst>
not supporting it yet, but yeah...
<karolherbst>
I wonder what we do currently if.. well.. if the local group is like 15 threads
<karolherbst>
do we return 32? do we return 15?
<karolherbst>
but what's also confusing, that it seems gl_SubGroupSizeARB is defined like max_sub_group_size
<karolherbst>
I'll just use SYSTEM_VALUE_SUBGROUP_SIZE until it breaks :shrug:
<karolherbst>
I'm sure the CTS will tell me if I do something incorrectly
<karolherbst>
airlied: funky.. there is also get_enqueued_num_sub_groups....
<karolherbst>
who even needs all of this
<gfxstrand>
karolherbst: Yeah... Been throwing you stuff on Mastodon
<gfxstrand>
Not been paying attention to IRC today
<karolherbst>
fair
<karolherbst>
I'll deal with subgroups first anyway
<gfxstrand>
fair
<karolherbst>
this starts to become serious API work :'(
<karolherbst>
clGetKernelSubGroupInfo is already a mess
<gfxstrand>
Ugh
<gfxstrand>
I can imagine
<karolherbst>
yeah soo
<karolherbst>
it is for querying limits, but it also imputs the block dimension...
<karolherbst>
quite painful
<karolherbst>
I think I'll cheat my way out
YuGiOhJCJ has joined #dri-devel
<karolherbst>
`ERROR: get_max_subgroup_size() doesn't match result from clGetKernelSubGroupInfoKHR, 16 vs 32` :)
<karolherbst>
*sigh*
<karolherbst>
this is probably my fault
<karolherbst>
for a given shader in iris, how can I figure out what's the max supported subgroup size?
andremorishita1 has joined #dri-devel
andremorishita has quit [Read error: Connection reset by peer]
andremorishita1 is now known as andremorishita
camus has joined #dri-devel
pallavim has joined #dri-devel
JohnnyonF has joined #dri-devel
Johnny has joined #dri-devel
andremorishita has quit [Quit: andremorishita]
JohnnyonFlame has quit [Ping timeout: 480 seconds]
JohnnyonF has quit [Ping timeout: 480 seconds]
rcf has joined #dri-devel
psykose has quit [Remote host closed the connection]
<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
<kode54>
rebuilding the newly rebased drm-xe-next kernel (whee, it's now on 6.3.0)
<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
<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
<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
<gfxstrand>
Yeah, let's make sure we fix those before they become immutable uAPI.
<gfxstrand>
mbrost__: ^^
<mbrost__>
yep
<gfxstrand>
kode54: Just to be clear, those are because uint64_t only has a 4B alignment on 32-bit builds, right?
<kode54>
yes
<gfxstrand>
kode54: Thanks for catching that!
<kode54>
actually, mlankhorst caught it first, to be honest
<mbrost__>
We have probably about a year before the uAPI is immutable
<kode54>
but his attempt to fix it also rewrites a lot of the headers
<mbrost__>
but probably can fix this pretty quickly
<kode54>
and breaks compatibility with 64 bit userspace that already uses the headers
<kode54>
(thanks, Intel, for already releasing "release" software that implements this)
aravind has joined #dri-devel
<mbrost__>
just gotta coordinate IGTs + UMDs + KMD
<mbrost__>
I'll bring this up with the team and try get this moving
<airlied>
what released software has it?
<kode54>
intel-compute-runtime implements Xe in 23.09
<airlied>
if any software has this stuff merged into it's master before it lands in the kernel, that's a pretty big screwup
<airlied>
you might end up having to burn the whole uapi down
<kode54>
my attempt only makes the corrections necessary to ensure 32/64 match the existing header
lemonzest has quit [Quit: WeeChat 3.6]
<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
<mbrost__>
afaik we are not releasing any UMDs based on Xe, we might have public branches
<airlied>
better check intel-compute-runtime hasn't messed up the plan
<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
<gfxstrand>
Oh, I assume either intel-compute-runtime or intel-media-driver will mess it up.
<kode54>
intel-media-driver only has an unmerged "DO NOT MERGE" MR
<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
<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
<gfxstrand>
But, yes, they need to very much not do that
<kode54>
the media runtime one doesn't even include the xe_drm.h
<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
<mbrost__>
i will check on this now...
<airlied>
if it's behind some flag or not on by default that is less worrying
<gfxstrand>
airlied: Yeah, I get that.
<kode54>
Arch isn't distributing 23.xx yet
<mbrost__>
probably be until the us morning though to get a response
<kode54>
I got them with a -bin AUR package that pulls directly from Intel's github
<kode54>
gonna reboot into this new kernel, and check if the compute runtime suddenly works again
<kode54>
(one struct I shouldn't have padded)
<kode54>
yup, intel-compute-runtime-bin works again
<kode54>
or at least doesn't crash
<kode54>
let's see if I can actually get it to compute some things now
<kode54>
yeah, nah, intel-compute-runtime hangs the engine once again
<kode54>
the intel-media-driver PR even hardcodes a PCI ID for a tigerlake device
psykose has joined #dri-devel
q66 has quit [Ping timeout: 480 seconds]
q66 has joined #dri-devel
dcz has joined #dri-devel
pallavim has joined #dri-devel
mbrost has joined #dri-devel
mbrost_ has joined #dri-devel
mbrost__ has quit [Ping timeout: 480 seconds]
mbrost has quit [Ping timeout: 480 seconds]
Zopolis4 has joined #dri-devel
pallavim has quit [Ping timeout: 480 seconds]
bmodem has quit [Read error: Connection reset by peer]
pallavim has joined #dri-devel
aravind has quit [Ping timeout: 480 seconds]
bmodem has joined #dri-devel
jewins has quit [Ping timeout: 480 seconds]
mszyprow has joined #dri-devel
<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?
<airlied>
mlankhorst: yeah I can't pull that until rc1
<airlied>
because it requires backmerges
<airlied>
and I rarely feel it's that urgent
<mlankhorst>
yeah true, no worries
<airlied>
I suppose I could in theory just forward it to Linus as a separate pull outside of -next but it seems messier
<mlankhorst>
misc-next-fixes was empty anyhow
mdroper has quit [Ping timeout: 480 seconds]
sima has joined #dri-devel
Kayden has quit [Read error: Connection reset by peer]
Kayden has joined #dri-devel
<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
whald has quit [Remote host closed the connection]
Duke`` has joined #dri-devel
pcercuei has quit [Quit: brb]
mszyprow has joined #dri-devel
pcercuei has joined #dri-devel
tursulin has quit [Ping timeout: 480 seconds]
<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
JohnnyonFlame has quit [Ping timeout: 480 seconds]
<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...
tzimmermann has quit [Quit: Leaving]
<bl4ckb0ne>
might be a long shot, but does anybody here know about open positions (fulltime or contract) to work on linux graphics
<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
<rodrigovivi>
kode54: nevermind... we figured out where this build flag is coming from and have already requested them to remove it...
heat_ has joined #dri-devel
heat has quit [Read error: Connection reset by peer]
pochu has quit [Quit: leaving]
kts has quit [Quit: Konversation terminated!]
mszyprow has joined #dri-devel
rasterman has quit [Quit: Gettin' stinky!]
mszyprow has quit [Ping timeout: 480 seconds]
heat_ has quit [Read error: Connection reset by peer]
heat_ has joined #dri-devel
stuarts has quit [Remote host closed the connection]
vliaskov has quit [Remote host closed the connection]
kts has joined #dri-devel
heat__ has joined #dri-devel
heat_ has quit [Read error: Connection reset by peer]
JohnnyonFlame has joined #dri-devel
DPA has quit [Ping timeout: 480 seconds]
mbrost has joined #dri-devel
mbrost_ has joined #dri-devel
mbrost has quit [Ping timeout: 480 seconds]
ngcortes has joined #dri-devel
Haaninjo has joined #dri-devel
smiles_1111 has quit [Ping timeout: 480 seconds]
junaid has joined #dri-devel
DPA has joined #dri-devel
FireBurn has quit [Quit: Konversation terminated!]
jfalempe has quit [Read error: Connection reset by peer]
jfalempe has joined #dri-devel
illwieckz has quit [Quit: I'll be back!]
illwieckz has joined #dri-devel
junaid has quit [Quit: leaving]
kts has quit [Ping timeout: 480 seconds]
Daanct12 has joined #dri-devel
<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
<sima>
or maybe move that to the uapi section and add a link to the property section, might be even better
<sima>
or ping me when you have something since I'll probably miss
junaid has joined #dri-devel
Danct12 has quit [Ping timeout: 480 seconds]
mvlad has quit [Remote host closed the connection]
tirixta has joined #dri-devel
<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
junaid has quit [Ping timeout: 480 seconds]
Company has joined #dri-devel
junaid has joined #dri-devel
kts has joined #dri-devel
kts has quit []
heat has joined #dri-devel
heat__ has quit [Read error: No route to host]
junaid_ has joined #dri-devel
kts has joined #dri-devel
tirixta has quit [autokilled: Spambot. Mail support@oftc.net if you think this is in error. (2023-05-05 20:18:09)]
sima has quit [Ping timeout: 480 seconds]
pallavim has quit [Ping timeout: 480 seconds]
rasterman has joined #dri-devel
tirixta has joined #dri-devel
heat has quit [Read error: Connection reset by peer]
heat has joined #dri-devel
tirixta has quit [autokilled: Spambot. Mail support@oftc.net if you think this is in error. (2023-05-05 20:30:40)]
heat has quit [Remote host closed the connection]
heat has joined #dri-devel
Duke`` has quit [Ping timeout: 480 seconds]
cagalicious has joined #dri-devel
cagalicious has quit [autokilled: Spambot. Mail support@oftc.net if you think this is in error. (2023-05-05 20:34:47)]
junaid has quit [Ping timeout: 480 seconds]
junaid_ has quit [Ping timeout: 480 seconds]
Daaanct12 has joined #dri-devel
fxkamd has quit []
pallavim has joined #dri-devel
Daanct12 has quit [Ping timeout: 480 seconds]
pallavim has quit [Ping timeout: 480 seconds]
thellstrom has quit [Ping timeout: 480 seconds]
fxkamd has joined #dri-devel
pallavim has joined #dri-devel
dcz has quit [Ping timeout: 480 seconds]
illwieckz has quit [Remote host closed the connection]
Haaninjo has quit [Quit: Ex-Chat]
fxkamd has quit []
bgs has quit [Remote host closed the connection]
kts has quit [Quit: Konversation terminated!]
ngcortes has quit [Ping timeout: 480 seconds]
apinheiro has joined #dri-devel
illwieckz has joined #dri-devel
apinheiro has quit [Quit: Leaving]
mbrost_ has quit [Ping timeout: 480 seconds]
pcercuei has quit [Quit: dodo]
alanc has quit [Remote host closed the connection]