ChanServ changed the topic of #dri-devel to: <ajax> nothing involved with X should ever be unable to find a bar
Leopold_ has quit [Remote host closed the connection]
luc4 has quit []
Leopold_ has joined #dri-devel
jdavies has joined #dri-devel
jdavies is now known as Guest2731
jdavies_ has joined #dri-devel
Guest2731 has quit [Ping timeout: 480 seconds]
mattst88 has quit [Quit: leaving]
pcercuei has quit [Quit: dodo]
camus1 has quit [Remote host closed the connection]
camus has joined #dri-devel
mattst88 has joined #dri-devel
co1umbarius has joined #dri-devel
columbarius has quit [Ping timeout: 480 seconds]
YuGiOhJCJ has joined #dri-devel
mattst88 has quit [Quit: leaving]
mattst88 has joined #dri-devel
angerctl has joined #dri-devel
danvet has quit [Ping timeout: 480 seconds]
Namarrgon has quit [Ping timeout: 480 seconds]
bluetail89482 has joined #dri-devel
dsrt^ has joined #dri-devel
lemonzest has joined #dri-devel
Leopold_ has quit [Ping timeout: 480 seconds]
alyssa has joined #dri-devel
<alyssa>
dschuermann_: nir: Use SM5 properties to optimize shift(a@32, iand(31, b))
<alyssa>
<alyssa>
This is a common pattern from HLSL->SPIRV translation
<alyssa>
and supported in HW by all current NIR backends.
<alyssa>
So... about that.. we've since added a NIR backend for AGX which doesn't define shifts this way
<alyssa>
which means Asahi is unsound
* alyssa
sweats
<alyssa>
I don't want to add back the `iand` to every shift in the backend, since it's UB in the GLSL spec, that'd be pointless
<alyssa>
but I don't want to revert that optimization since it's doing good for every other backend (including Panfrost)
<alyssa>
options include defining more specialized `ishl_sm5`, etc opcodes that regular ishl gets lowered to... but that requires touching every backend
<alyssa>
or defining `ishl_nonsm5` that lowers to `ishl`... but that requires touching every frontend
<alyssa>
or gating that optimization behind an option, but I've NAK'd exactly that before and I'm NAK'ing it from myself here now too :-p
<alyssa>
or closing my eyes and pretending AGX is less special
<alyssa>
Apple's compiler leaves the iand in when compiling `1 << (x & 31)`, so it's not like there's a special DirectX mode the instruction has
<alyssa>
oh, wait, maybe Apple *inserts* the iand for any dynamic shift operand, uh
<alyssa>
yeah, ok. apple is adding the iand in the backend for shifts. that's... curious.
<alyssa>
oh, because Metal's shading language deviates from C++ and instead defines shifts as:
<alyssa>
"The result of E1 << E2 is E1 left-shifted by the log2(N) least significant bits in E2 viewed as an unsigned integer value"
<alyssa>
and likewise for >>
<alyssa>
i.e. the NIR/SM5 definition
<alyssa>
Kinda curious. Why would Apple define their hw to work differently than Metal is defined?
djbw has joined #dri-devel
<alyssa>
shrug. if it's good enough for apple, it's good enough for me
Leopold_ has joined #dri-devel
bluetail89482 has quit [Ping timeout: 480 seconds]
graphitemaster has quit [Ping timeout: 480 seconds]
<jenatali>
alyssa: Add a nir option to turn off that optimization for AGX?
<jenatali>
Oh sorry I missed in your wall of text you don't want to do that :P
<jenatali>
Still seems like the sanest option to me
<hays>
ok.. So this implies Vulkan Loader is open and GPU vendor just provides a driver
<X512>
Vulkan-Loader is open source (Apache License 2.0). It is cross platform and used by many operating systems including Windows.
<hays>
I got this cryptic email from a GPU/SOC vendor: "the mali vulkan is not released yet and only support drm now(no wayland or x11)"
<X512>
In Mesa Vulkan drivers are located at src/<vendor>/vulkan.
<hays>
im trying to make sense of that email --it seems like the vulkan driver has no knowledge of windowing system etc
<X512>
And generic code used by all Mesa Vulkan drivers in src/vulkan.
<X512>
Mesa Vulkan drivers have knowledge of windowing system (WSI). But it is also possible to implement windowing system support in separate Vulkan layer module.
ybogdano has joined #dri-devel
<hays>
i suppose doing so would require looking at the shared library and seeing what function calls were not implemented and then writing that layer
<X512>
You can write Vulkan WSI layer to add windowing system support to existing driver.
<hays>
yeah, or maybe it sounds like one already exists and I could try to use it
<hays>
I am currently testing a hypothesis that the Mali vendor blob wayland-gbm is unnecessary when used with wayland because they cleaned up the interface with libwayland-egl.so
<hays>
My hope is that, if this holds, when they release vulkan support it can be similarly adapted (maybe via a WSL layer) to use
<alyssa>
jenatali: The problem there is that the NIR opcode (ishl etc) then has different behaviour/meaning depending on the backend
<alyssa>
and having an inconsistent NIR is not a good idea
<jenatali>
Fair
<alyssa>
glehmann: The problem there is that we still lose information
<hays>
then of course once v10 comes out we swich over to open drivers :)
<alyssa>
if the shift came from GLSL or SPIR-V, we may asume wlog that the shift is < 32
<alyssa>
but just looking at the ishl instruction, range analysis can't assume that because of the sm-5 definition
<alyssa>
again, Apple is masking every shift, so I may as well do the same.
<alyssa>
I'm not going to be iand-due-to-nonconstant-shift bound, lol
<alyssa>
non-constant shifts aren't super common anyway
<alyssa>
got bigger fish to fry
mattst88 has joined #dri-devel
<alyssa>
jenatali: I think the right way to do this, if this mattered for a hot path, would be to introduce new `{ishl,ishr,ushr}_khr` NIR opcodes that are undefined for shift >= 32
<alyssa>
generate _khr versions in GLSL-to-NIR and SPIRV-to-NIR, where we have a spec reference saying it's safe to do so
<alyssa>
(but don't replace it throughout the tree, maybe there's a common lowering pass somewhere that relies on the existing SM5 semantics of ishl, do we really want to audit the tree due to walking back on a previous opcode definitional guarantee?)
<alyssa>
replace the SM5 optimizations to be "ishl_khr(1, a & 31) -> ishl(1, a)"
<alyssa>
have a "has_khr_shifts" compiler option that indicates a backend can accept the _khr versions *in addition* to the regular sm5 versions, which only AGX would set
<alyssa>
AGX would have a late backend lowering "ishl(a, b) -> ishl_khr(a, b & 31)"
<alyssa>
and AGX would only handle the _khr versions, while everyone else would only handle the nonsuffixed sm5 versions
<alyssa>
that being said, that sounds like a big pile of work for something Apple doesn't bother to do, for the purpose of exploiting UB and that's maybe not great
<alyssa>
so instead I think I'll do the subset: add _khr opcodes, lower to them in the backend, and handle only _khr versions
gouchi has joined #dri-devel
<alyssa>
and if someone really wants to get rid of the extra iands they can plumb that through the glsl/spirv translators
<hays>
i mean this client is for some reason doing both EGL and Vulkan at same time it would obv pick one
<X512>
Maybe proprietary driver use EGL as WSI implementation, I don't know. It is possible to convert VkImage/VkDeviceMemory to EGLImage and display with EGL mechanisms.
<hays>
well I think they just blob it together within the same driver even if they are different. the way GLESv2, GBM, and EGL are blobbed together
rasterman has quit [Quit: Gettin' stinky!]
<hays>
right now im hearing from rockchip they are not supporting wayland+vulkan just straight drm
<hays>
but doesn't that mean IF wayland were to implement vulkan-wsi-layer, the system would essentially be wayland enabled?
djbw has quit [Read error: Connection reset by peer]
Duke`` has quit [Ping timeout: 480 seconds]
jluthra has quit [Remote host closed the connection]
jluthra has joined #dri-devel
Duke`` has joined #dri-devel
X512 has quit [Quit: Vision[]: i've been blurred!]
Dr_Who has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
Dr_Who has joined #dri-devel
RSpliet has quit [Quit: Bye bye man, bye bye]
RSpliet has joined #dri-devel
agd5f_ has joined #dri-devel
agd5f has quit [Ping timeout: 480 seconds]
peelz has joined #dri-devel
Dr_Who has quit []
agd5f has joined #dri-devel
Dr_Who has joined #dri-devel
agd5f_ has quit [Ping timeout: 480 seconds]
jewins has joined #dri-devel
bb2045 has joined #dri-devel
Dr_Who has quit []
Dr_Who has joined #dri-devel
vyivel has quit [Remote host closed the connection]
vyivel has joined #dri-devel
vyivel has quit [Remote host closed the connection]
vyivel has joined #dri-devel
gbelgurr has quit []
Dr_Who has quit []
junaid_ has quit [Remote host closed the connection]
junaid__ has quit [Remote host closed the connection]
junaid has quit [Remote host closed the connection]
gouchi has quit [Remote host closed the connection]
<bb2045>
Hi all. I've written a 3D engine. Source code not public atm. With task/mesh shaders, I have encountered NIR validation errors. Could these shader files potentially be of use to mesa's development?
sarnex has joined #dri-devel
agd5f_ has joined #dri-devel
Duke`` has quit [Ping timeout: 480 seconds]
agd5f has quit [Ping timeout: 480 seconds]
kzd has quit [Ping timeout: 480 seconds]
jewins has quit [Ping timeout: 480 seconds]
kzd has joined #dri-devel
Jeremy_Rand_Talos_ has quit [Remote host closed the connection]