<karolherbst>
ahh yeah.. it also appears at private for me, but I can access it
<mbrost>
ah, try it again
<kisak>
there it is
<daniels>
mbrost: can you please re-do the CI to use the GitLab kernel CI stuff we've already been working on?
<daniels>
mbrost: as is, installing the deps every time is quite inefficient, and not using ${FDO_CI_CONCURRENT] is a DoS on the runners
<mbrost>
Probably, I wasn't involved in setting that up
<daniels>
demarchi: ^
<mbrost>
yep, demarchi is who you should talk to
<mbrost>
I can bring up this up with the entire Xe team too
<karolherbst>
what's the situation with hosting kernel projects on gitlab now anyway? Wouldn't that fill up storage real quick if everybody forks to submit MRs? Or is that considered fine now? (also ignoring that it takes ages to fork anyway)
<karolherbst>
(just wondering how we can ditch emails for kernel devel here anyway)
<daniels>
I think we're ok for storage
<daniels>
mbrost: yeah, if you could please ask them to just follow the rest of the kernel CI work, as in e.g. drm-msm, that would be great please
<daniels>
karolherbst: I don't see a real blocker to moving kernel stuff to GitLab; the only risk is that we overwhelm the infrastructure and need to ask our hosts for more
<karolherbst>
right..
<karolherbst>
but having to fork the kernel repo for an hour before you can submit an MR is also kind of annoying if the alternative is to send an email out in 5 seconds, but that's nothing _we_ can fix and is in the hands of gitlab itself
<jenatali>
karolherbst: I don't think the forks are full forks, assuming it works like GitHub, I think it's just a namespace for branches
<karolherbst>
anyway.. if drm-msm is atm the most advanced project in regards to CI and stuff, I might be up to move to gitlab for nouveau as well, just... that makes it annoying because we still have to consider emails, because we can't tell users to do the gitlab dance instead :/
<karolherbst>
jenatali: well.. did you try to fork a kernel on gitlab?
<karolherbst>
last time I tried, it took like an hour
<jenatali>
That seems insane
<karolherbst>
I'm thinking the same
heat has quit [Ping timeout: 480 seconds]
<karolherbst>
maybe it's better now...
<karolherbst>
could fork xe/kernel and see what happens
<mbrost>
I fork Xe all the time, it takes like 5-10 minutes
<karolherbst>
right.. but the thing is, on github it's almost instantly
<mbrost>
to be clear this our internal project, we plan on moving to the mailing list model soon
<karolherbst>
don't bother with mailing lists 🙃
<mbrost>
In perfect world yea I'd like to use gitlab as I much prefer that flow vs. mailing lists
<karolherbst>
just do it 🙃
<jenatali>
5-10 minutes still seems crazy. I wonder if it is doing a real fork. That seems like bad design
<karolherbst>
afaik it is doing a real fork
<mbrost>
rodrigovivi is driving our strategy for getting Xe upstream / the upstream development flow
<karolherbst>
rodrigovivi: pls don't bother with a mailing list 🙃 (I'd totally love if drm would be the first subsystem to be like: "you sent a what? just use gitlab like normal people!"
<daniels>
it is doing a real fork, but it's not duplicating storage
<karolherbst>
why does forking take so long then?
<daniels>
mostly building indices afaik
oneforall2 has quit [Remote host closed the connection]
<karolherbst>
ahh yeah.. it took like 5 minutes indeed
oneforall2 has joined #dri-devel
<daniels>
x.org has a contact with gitlab community people, could always take it up with them
<karolherbst>
maybe I just did cursed things with the nouveau one... let's see
<karolherbst>
btw, does drm-msm has some patchwork updating stuff set up? Otherwise I'll try my stuff out with nouveau and see how that works out
lemonzest has quit [Quit: WeeChat 3.6]
martijnbraam1 is now known as martijnbraam
Leopold_ has quit [Remote host closed the connection]
lemonzest has joined #dri-devel
Leopold_ has joined #dri-devel
mbrost_ has joined #dri-devel
mbrost has quit [Remote host closed the connection]
pallavim has quit [Ping timeout: 480 seconds]
alanc has quit [Remote host closed the connection]
alanc has joined #dri-devel
OftenTimeConsuming has joined #dri-devel
bluetail89482210 has joined #dri-devel
<demarchi>
daniels: currently there is only 1 runner allowed to run and it already has all deps installed, so not a big issue. Now that it's public, iff we want to use the fdo runners (should we?) we could rethink that
aravind has joined #dri-devel
bluetail8948221 has quit [Ping timeout: 480 seconds]
illwieckz_ has joined #dri-devel
illwieckz has quit [Ping timeout: 480 seconds]
alyssa has joined #dri-devel
alanc has quit [Remote host closed the connection]
jdavies_ has joined #dri-devel
alanc has joined #dri-devel
Guest2934 has quit []
srslypascal is now known as Guest2965
srslypascal has joined #dri-devel
srslypascal has quit []
srslypascal has joined #dri-devel
Guest2954 has quit [Ping timeout: 480 seconds]
Guest2965 has quit [Ping timeout: 480 seconds]
ybogdano has joined #dri-devel
ybogdano has quit []
<demarchi>
daniels: mbrost_ but should probably talk with DragoonAethis / Radek. Not sure what the plans are for the CI... the gitlab setup is not being used for running tests, that is done in jenkins
<demarchi>
mbrost_: and Maciej... not sure if they are in this channel
ybogdano has joined #dri-devel
mbrost_ has quit [Remote host closed the connection]
sarnex has quit [Read error: Connection reset by peer]
mbrost_ has joined #dri-devel
sarnex has joined #dri-devel
srslypascal is now known as Guest2972
srslypascal has joined #dri-devel
Guest2972 has quit [Ping timeout: 480 seconds]
RSpliet has quit [Quit: Bye bye man, bye bye]
RSpliet has joined #dri-devel
YuGiOhJCJ has joined #dri-devel
YuGiOhJCJ has quit [Remote host closed the connection]
YuGiOhJCJ has joined #dri-devel
<anholt>
wonder why dxvk doesn't like my RADV_PERFTEST=gpl :/
ngcortes has quit [Ping timeout: 480 seconds]
mbrost_ has quit [Ping timeout: 480 seconds]
elongbug_ has quit [Read error: Connection reset by peer]
RSpliet has quit [Quit: Bye bye man, bye bye]
RSpliet has joined #dri-devel
oneforall2 has quit [Remote host closed the connection]
illwieckz_ has quit []
illwieckz has joined #dri-devel
YuGiOhJCJ has quit [Remote host closed the connection]
YuGiOhJCJ has joined #dri-devel
Company has quit [Quit: Leaving]
RSpliet has quit [Quit: Bye bye man, bye bye]
RSpliet has joined #dri-devel
kzd has quit [Quit: kzd]
itoral has joined #dri-devel
jewins has quit [Read error: Connection reset by peer]
RSpliet has quit [Quit: Bye bye man, bye bye]
jewins has joined #dri-devel
RSpliet has joined #dri-devel
thellstrom has joined #dri-devel
junaid has joined #dri-devel
junaid has quit [Remote host closed the connection]
RSpliet has quit [Quit: Bye bye man, bye bye]
RSpliet has joined #dri-devel
ice99 has joined #dri-devel
oneforall2 has joined #dri-devel
ice99 has quit [Remote host closed the connection]
gouchi has quit [Remote host closed the connection]
jkrzyszt has joined #dri-devel
sghuge has quit [Remote host closed the connection]
sghuge has joined #dri-devel
agd5f_ has joined #dri-devel
agd5f has quit [Ping timeout: 480 seconds]
djbw has quit [Read error: Connection reset by peer]
heat has quit [Ping timeout: 480 seconds]
danvet has joined #dri-devel
xroumegue has quit [Ping timeout: 480 seconds]
tursulin has joined #dri-devel
phasta has joined #dri-devel
xroumegue has joined #dri-devel
vliaskov has joined #dri-devel
<tzimmermann>
mripard, mlankhorst, danvet, i'm trying to update drm-misc-next-fixes . wasn't this supposed to be as simple as 'git merge --ff-only drm-misc/drm-misc-next' ? that command fails
<danvet>
tzimmermann, two patches only landed in drm-fixes aftera drm-next took off
<danvet>
so ff not possible
<danvet>
I guess we could backmerge or you just force the update
<tzimmermann>
thanks, i do the backmerge
<danvet>
those 2 patches only made it into -rc3
<danvet>
well drm-next also hasn't moved yet
<tzimmermann>
danvet, is there a git option to show such conflicts?
<danvet>
git log drm-next..drm-misc-next-fixes
<danvet>
well drm-misc-next..drm-misc-next-fixes
<tzimmermann>
oh, too easy :D
<danvet>
:-)
<danvet>
airlied, ^^ should we backmerge?
kts has quit [Remote host closed the connection]
kts has joined #dri-devel
<airlied>
danvet: yeah might be a good time
jkrzyszt has quit [Remote host closed the connection]
kts has quit [Quit: Leaving]
<danvet>
airlied, ok will do since I guess a bit late on your end
<danvet>
tzimmermann, ^^ you get a ping, might be a bit since I have meetings starting now
<tzimmermann>
don't worry
<danvet>
tzimmermann, maybe also backmerge into drm-misc-next so it's not out of sync too much either
frankbinns has joined #dri-devel
<tzimmermann>
of course
rasterman has joined #dri-devel
lynxeye has joined #dri-devel
jkrzyszt has joined #dri-devel
apinheiro has joined #dri-devel
<cwabbott>
gfxstrand: looks like I'm gonna have to add interval trees to your rb tree thing
<cwabbott>
ofc this is like 15 steps removed from some other project
jluthra_ has joined #dri-devel
jluthra has quit [Ping timeout: 480 seconds]
pcercuei has joined #dri-devel
ahajda has joined #dri-devel
chloekek has joined #dri-devel
sgruszka has joined #dri-devel
ahajda_ has joined #dri-devel
jdavies__ has joined #dri-devel
fab has quit [Quit: fab]
fab has joined #dri-devel
ahajda has quit [Ping timeout: 480 seconds]
RSpliet has quit [Quit: Bye bye man, bye bye]
RSpliet has joined #dri-devel
jdavies_ has quit [Ping timeout: 480 seconds]
Lightsword has quit [Read error: Connection reset by peer]
ahajda_ has quit []
ahajda_ has joined #dri-devel
dabrain34[m] has joined #dri-devel
apinheiro has quit [Read error: Connection reset by peer]
bluetail89482210 has quit []
bluetail89482210 has joined #dri-devel
Lightsword has joined #dri-devel
heat has joined #dri-devel
devilhorns has joined #dri-devel
bluetail89482210 has quit []
bluetail has joined #dri-devel
<bluetail>
so if I compile mesa-git with 'gallium-drivers=virgl', how can I use it then in virt-manager? I am confused by the instruction given at https://wiki.archlinux.org/title/QEMU#virtio and I would be happy for a pointer. Hopefully this is the right place to ask
<bluetail>
I wonder though, it doesnt steal the vga from the host, as in pcie passthrough, right?
<HdkR>
Correct
<HdkR>
It's API passthrough using a virtualized GPU effectively
<bluetail>
Cool. Any pointers in how to use it in virt-manager ? I am just very confused by the instruction given.
<javierm>
bluetail: you need to add a virt-gpu device
<bluetail>
oh. that makes sense. thanks
apinheiro has joined #dri-devel
sgruszka has quit [Remote host closed the connection]
Sachiel has quit [Ping timeout: 480 seconds]
YuGiOhJCJ has quit [Quit: YuGiOhJCJ]
Lightsword has quit [Quit: ZNC]
kts has joined #dri-devel
<bluetail>
I did those things. But virt-manager running windows 10 still seems stuttery.
<bluetail>
is the acceleration working even at all with win 10?
<bluetail>
I think I did do something wrong. Cause virtio-vga is not listed in dmesg
<bluetail>
but I was able to select virtio with 3d acceleration and my 6950xt ...
Lightsword has joined #dri-devel
Lightsword has quit []
<bluetail>
nvm... "the guest needs a driver for virgl, which as someone mentioned was never fully written for windows"
<danvet>
tzimmermann, backmerge pushed, I had some fun with the fb helper conflicts :-)
<tzimmermann>
danvet, thanks a lot
<danvet>
airlied, agd5f_ tursulin dolphin jani rodrigovivi ^^ fyi drm-next is now at -rc6
Lightsword has joined #dri-devel
mvlad has quit [Remote host closed the connection]
<javierm>
bluetail: ah, I only used Linux both as host and guest, have no idea how to do it with Windows as a guest
Piraty has joined #dri-devel
kts has quit [Quit: Leaving]
itoral has quit [Remote host closed the connection]
<DragoonAethis>
demarchi, mbrost, daniels: I'm here, just rarely visiting IRC - regarding CI we're in the middle of a cleanup project that should make it easier to work across mailing lists and GitLab, but in general most of it won't be driven from GitLab
<DragoonAethis>
It should be able to report results in a nicer way to GitLab though, instead of just posting loose comments as it does now
<bluetail>
javierm it turned out to be not good enough. Although then I had 60fps and 1920x1080, it was still too choppy and I couldnt get my audio stuff working and so chose another path.
fxkamd has joined #dri-devel
gfxstrand has quit [Quit: leaving]
gfxstrand has joined #dri-devel
jewins1 has joined #dri-devel
phasta has joined #dri-devel
jewins has quit [Ping timeout: 480 seconds]
lstrano has joined #dri-devel
pzanoni has quit [Ping timeout: 480 seconds]
pallavim has joined #dri-devel
lstrano_ has quit [Ping timeout: 480 seconds]
pzanoni has joined #dri-devel
kzd has joined #dri-devel
pallavim has quit [Ping timeout: 480 seconds]
cars^ has quit [Remote host closed the connection]
Duke`` has joined #dri-devel
cphealy_ has quit []
cphealy has joined #dri-devel
<Ristovski>
Related to the questions asked by X512, is there some document outlining missing features for hardware? I feel like some of them could be "low hanging fruit" for people who would like to put in some time to improve their old hardware support
<Ristovski>
For example, I learned that amdgpu on SI (and CIK?) does not support VAAPI hw simply because no one ported over the required bits from radeonsi (I am sure it would be tedious due to differences in the driver architecture). I am sure there are other such examples
<Ristovski>
As they say, never underestimate the motivation of a bored person :P
<kisak>
"ported over the required bits from radeonsi" radeonsi being the mesa OpenGL driver does not make sense for a topic on vaapi. Did you mean radeon kernel module to amdgpu kernel module?
<Ristovski>
kisak: oh oops, yes
<X512>
UVD handling was recently added to kernel amdgpu driver for SI GPUs.
<Ristovski>
But not VCE, iirc
<X512>
Why radeon driver is still enabled as default for SI GPUs, not amdgpu? radeon driver do not work with RADV.
<MrCooper>
Ristovski: DRM modifiers aren't really low hanging fruit, the video acceleration issue was more complicated than that as well (related to the required microcode)
<Ristovski>
vainfo on my old machine seems to agree, only UVD is implemented on amdgpu
agd5f_ has quit []
<Ristovski>
MrCooper: sorry, I gave a bad example for arguments sake as I couldn't remember anything else off the top of my head. However the point of "more documentation is better" still holds :P
agd5f has joined #dri-devel
<MrCooper>
X512: amdgpu doesn't support all the same functionality as radeon for older GPUs, and there's a high risk of regressions due to the huge number of systems running with radeon in the wild
<X512>
What kind of documentation do amdgpu developers refer? Something under NDA?
phasta has quit [Remote host closed the connection]
<agd5f>
X512, most developers work for AMD
<MrCooper>
I'd say better than switching the default would be making it easier for users to switch explicitly
<Ristovski>
I would assume so, the public information (stuff like ISA documentation) is quite lacking, especially for something like registers and other firmware related docs
<emersion>
they have some kernel docs
<emersion>
mostly high level overviews though
<emersion>
headers have registers
<X512>
It seems almost no documentation for low level GPU control such as loading firmwares, setup ring buffers, initalize RLC (not sure what is it exactly).
<X512>
Wrong GPU initialization order cause weirld issues like whole PC freeze.
<Ristovski>
emersion: I wouldn't really call those useful for anyone who isn't intimately familiar with the HW. A huge list of register names and their offsets (or values for chicken registers et al) without a note stating what they are for is hardly useful
<agd5f>
Ristovski, the vast majority of them are not really relevant to SW developers either. The driver only touches a small handful of them. The vast majority are really only interesting to HW designers.
<Lyude>
Ristovski: send an email to board@foundation.x.org
fab has quit [Quit: fab]
aravind has quit [Ping timeout: 480 seconds]
nchery has joined #dri-devel
linyaa has quit [Quit: WeeChat 1.9.1]
linyaa has joined #dri-devel
tursulin has quit [Ping timeout: 480 seconds]
ajax_ has joined #dri-devel
ajax has quit [Ping timeout: 480 seconds]
junaid has joined #dri-devel
djbw has joined #dri-devel
lynxeye has quit [Quit: Leaving.]
nchery is now known as Guest3029
nchery has joined #dri-devel
Guest3029 has quit [Ping timeout: 480 seconds]
<daniels>
Ristovski: you could also take the nouveau wiki bits which generate a GitLab Pages tree from ikiwiki source, which is exactly what we need
<daniels>
that can be done from a personal repo
X512 has quit [Quit: Vision[]: i've been blurred!]
<alyssa>
mareko: anholt: It looks like, if SHAREABLE_SHADERS are supported, shader_has_one_variant is just checking desktop GL support
<alyssa>
Is shader_has_one_variant expected to be true for GLES contexts on GLES drivers (that otherwise rely on mesa/st variants for big GL)?
<airlied>
danvet: thanks!
<alyssa>
e.g. for vertex shaders, it checks clamp_vert_color_in_shader, lower_point_size, and lower_ucp
<alyssa>
none of which should be required on GLES
<alyssa>
(but which are set directly based on the CAPs without checking the API)
<alyssa>
ditto for fragment shaders (provided the driver doesn't need flatshading lowered or persample forced)
<anholt>
alyssa: anything I might have known about that is long since forgotten
<alyssa>
anholt: 100% valid
<alyssa>
thanks anyway :)
<alyssa>
hmm my drivers do need flatshading lowered, but maybe that's big GL only
<alyssa>
I know Mali architecturally isn't supposed to require variants for anything in GLES or VK
<alyssa>
right flatshade lowering is only for ShadeModel == GL_FLAT which afaik is a big GL only thing
<alyssa>
so yeah, my drivers ought to qualify for the fast path in GLES contexts, if not for the checks
jkrzyszt has quit [Ping timeout: 480 seconds]
gouchi has joined #dri-devel
Sachiel has joined #dri-devel
<alyssa>
oh, but we precompile a default variant anyway
<alyssa>
that check is just about avoiding some hashing/lookups at bind time
<alyssa>
less interesting ^^
<kusma>
alyssa: glShadeModel(GL_FLAT) exists in GLES 1, and is supported in HW on at least earlier Mali GPUs...
jdavies_ has joined #dri-devel
<kusma>
Ah, but you might still need to lower that to the shader...
jdavies__ has quit [Ping timeout: 480 seconds]
pcercuei has quit [Read error: Connection reset by peer]
pcercuei has joined #dri-devel
ajax has joined #dri-devel
ajax_ has quit [Ping timeout: 480 seconds]
maxzor__ has joined #dri-devel
<kusma>
For gles, we should be able to do that in the ff shader generator...
<anarsoul>
kusma: out of curiosity, is it supported on Utgard?
srslypascal has quit [Quit: Leaving]
ngcortes has joined #dri-devel
<alyssa>
kusma: i mean GLES2/3 by GLES here
maxzor__ has quit [Ping timeout: 480 seconds]
<alyssa>
"no shader variants for GLES2/3" is probably a design goal for Mali
<kusma>
Yup
<alyssa>
which Panfrost achieves on Bifrost and newer...
<alyssa>
on Midgard we have some rare variants when EXT_framebuffer_fetch is used with funny framebuffer formats
<alyssa>
but, close enough, nothing but the CTS hits that yet ;p
thellstrom has quit [Ping timeout: 480 seconds]
srslypascal has joined #dri-devel
tzimmermann has quit [Quit: Leaving]
iive has joined #dri-devel
maxzor__ has joined #dri-devel
bb2045 has quit [Remote host closed the connection]
lkw has joined #dri-devel
JohnnyonFlame has joined #dri-devel
junaid has quit [Ping timeout: 480 seconds]
jdavies__ has joined #dri-devel
jdavies_ has quit [Remote host closed the connection]
clever has joined #dri-devel
<gfxstrand>
Does Lyude not have a gitlab account?!?
sergi has joined #dri-devel
<danvet>
gfxstrand, lyudess
<alyssa>
Lyude: we have an MR that needs your crAcked-by
<gfxstrand>
😂
* alyssa
needs to stop designing Vulkan drivers for AGX and do her homework
<alyssa>
ella-0: i blame u <3 uwu
maxzor__ has quit [Ping timeout: 480 seconds]
Haaninjo has joined #dri-devel
apinheiro has quit [Ping timeout: 480 seconds]
<alyssa>
g
<gfxstrand>
q
junaid has joined #dri-devel
bgs has quit [Remote host closed the connection]
junaid has quit [Ping timeout: 480 seconds]
lkw has quit [Quit: leaving]
javierm_ has joined #dri-devel
javierm_ has quit []
danvet has quit [Ping timeout: 480 seconds]
apinheiro has joined #dri-devel
mvlad has quit [Remote host closed the connection]
<gfxstrand>
Does any hardware actually support write masks for global stores? I kinda don't think so.
gouchi has quit [Remote host closed the connection]
<pendingchaos>
GCN/RDNA AMD hardware doesn't support write masks for global stores
Duke`` has quit [Ping timeout: 480 seconds]
maxzor__ has joined #dri-devel
<gfxstrand>
I kinda think no one does.
<gfxstrand>
I'm thinking about how to generalize brw_nir_lower_mem_access_bit_sizes.c
<gfxstrand>
Intel is weird because it can do an unaligned scalar of 8, 16, or 32 bits or a dword-aligned dword vector of up to 4 components.
<gfxstrand>
IDK how to express that.
<gfxstrand>
I'm kinda thinking the callback should return a tuple (bit_size, max_comps_per_op)
rasterman has quit [Quit: Gettin' stinky!]
<gfxstrand>
Intel has some weird restrictions around load/store_scratch too. Need to figure those out.
mdnavare_ has joined #dri-devel
rsripada_ has joined #dri-devel
vliaskov has quit [Remote host closed the connection]
dolphin has quit [Ping timeout: 480 seconds]
mdnavare has quit [Ping timeout: 480 seconds]
rsripada has quit [Ping timeout: 480 seconds]
dolphin has joined #dri-devel
maxzor__ has quit [Ping timeout: 480 seconds]
maxzor__ has joined #dri-devel
nchery is now known as Guest3048
nchery has joined #dri-devel
unerlige1 has joined #dri-devel
fdu_ has joined #dri-devel
lstrano_ has joined #dri-devel
chloekek has quit [Quit: Leaving]
shankaru has quit [Ping timeout: 480 seconds]
unerlige has quit [Ping timeout: 480 seconds]
fdu has quit [Ping timeout: 480 seconds]
lstrano has quit [Ping timeout: 480 seconds]
Guest3048 has quit [Ping timeout: 480 seconds]
shankaru has joined #dri-devel
apinheiro has quit [Quit: Leaving]
<hays>
Is there a way to compile libEGL, libGBM, libGLESv* as one .so file
<emersion>
no…
Jeremy_Rand_Talos_ has quit [Remote host closed the connection]
Jeremy_Rand_Talos_ has joined #dri-devel
<hays>
it seems theoretically possible, but maybe the organization of the makefiles make it impractical
<emersion>
why would you ever want that anyways…
Jeremy_Rand_Talos_ has quit [Remote host closed the connection]
Jeremy_Rand_Talos_ has joined #dri-devel
<hays>
to implement a horrendous workaround
<psykose>
sounds better to fix the other thing
mbrost has joined #dri-devel
ahajda_ has quit [Read error: Connection reset by peer]
<jenatali>
Hm, is it expected that nir_intrinsic_load_push_constant doesn't have alignment info?
<jenatali>
That seems like an oversight
<jenatali>
gfxstrand: ^^ I think this is your domain
<gfxstrand>
Uh... No reason why we can't add it.
<jenatali>
Fair. Just was surprised it wasn't there. I assumed there was a good reason
<gfxstrand>
No one needed it yet. 🤷♀️
<gfxstrand>
bah. stupid terminal not knowing all the characters.
<gfxstrand>
I guess maybe I should consider using an IRC client from this millenia. 😅
<gfxstrand>
jenatali: Yeah, we should probably add it. The push constant space is an explicit layout space.
<jenatali>
Sounds good
<jenatali>
I want DOOM Eternal to work with Dozen, which means I get to add 16- and 8-bit type support. Except of course it doesn't follow CL alignment rules so now I have 6-byte alignments for stuff
<gfxstrand>
woof
<jenatali>
So I get to revisit all of the godawful lowering I had to write. Plus now push constants. Hooray
<jenatali>
But on the bright side I'm much smarter now than I was before :P
<gfxstrand>
:D
<jenatali>
I was also surprised that there's no alignments set on the casts from load_vulkan_descriptor
mbrost has quit [Ping timeout: 480 seconds]
<gfxstrand>
In ANV, we go through and set them as part of anv_nir_apply_pipeline_layout
<gfxstrand>
In order to generate them in spirv_to_nir, we'd need to have the min alignments from the API plumbed through to spirv_to_nir().
<gfxstrand>
I guess we could do that.
<gfxstrand>
What's the worst that happens? Someone doesn't set them and gets zero?
* gfxstrand
writes a patch
<jenatali>
I've got a patch for Dozen that adds them, yeah
<jenatali>
But I agree it'd be nice to do it in vtn rather than a "lowering" pass after the fact