ChanServ changed the topic of #dri-devel to: <ajax> nothing involved with X should ever be unable to find a bar
<ajax>
and for a project like qubes you'd think you'd _prefer_ fewer exploitable jits in any given process
<DemiMarie>
ajax: We don’t have anything that would be jitting untrusted code, and we are not even close to the point of enforcing strict W^X in Qubes userspace, sadly
<DemiMarie>
If someone wanted exploit Qubes, I suspect they would look for a vuln in Xen, which would bypass any userspace hardening
<ajax>
you get my point though. it's a big surface and clearly a pain point for you, so just don't have that problem. sorry about your pre-2012 radeon support in that case but meh.
<psykose>
actually that's a warning for 16 that will have that, for 15 it's still gcc 5.1 apparently with -DLLVM_TEMPORARILY_ALLOW_OLD_TOOLCHAIN=ON
<psykose>
i bet it's quite buildable
<DemiMarie>
interesting
<ajax>
way way way easier to just not have the problem than to try to make mesa able to contain its own c++ runtime
<ajax>
trust me, we tried, in fedora. it caused as many problems as it solved.
<DemiMarie>
main issue is going to be nvidia
<DemiMarie>
those drivers are often modesetting-only
<DemiMarie>
ajax: did you consider statically linking LLVM to its libc++?
Akari has quit [Ping timeout: 480 seconds]
<alyssa>
23:24 < DemiMarie> “use i3” isn’t going to fly with those people
<alyssa>
DemiMarie: I think XFCE/MATE without compositing or glamor is probably workable but yes understood
<alyssa>
23:25 < DemiMarie> the problem is that we need to support new hardware on an old distro
<DemiMarie>
alyssa: thank you
<alyssa>
this is fundamentally not workable when new hardware requires nontrivial changes (thousands of lines of code every time Arm releases a new Mali gen, for instance)
<alyssa>
23:43 < DemiMarie> Do most Linux graphics devs use Arch, Alpine Edge, or other rolling-release distros?
<alyssa>
based on shouldersurfing at XDC, i think Fedora is probably the most popular among this crowd
<DemiMarie>
alyssa: are these changes confined to Mesa and the kernel?
<alyssa>
23:55 < ajax> you get slow swrast, but whatever, and you lose some old pre-si radeons, but whatever
<alyssa>
ajax: don't all the radeons need llvm? unless you go the zink+radv route?
<alyssa>
00:00 < DemiMarie> ajax: We don’t have anything that would be jitting untrusted code, and we are not even
<alyssa>
Presumably if/when virgl is wired up, that would change? unless you had an alternate plan for 3D in not-dom0?
<alyssa>
DemiMarie: For Radeons, no, those are changes to all of Mesa, kernel, and LLVM.
<alyssa>
For everyone else, yes it's Mesa + kernel
<alyssa>
Nobody is backporting that to old Mesa's, or old LLVM's, it would be overly burdensome
<DemiMarie>
and nobody is asking you to 🙂
<alyssa>
sure, just preempting that ;)
<alyssa>
Now that I think about it, the more I'm wondering if this *is* a case of zink+radv, or at least radeonsi+aco
<DemiMarie>
what I am trying to figure out is if the Qubes devs can ship a new Mesa and new LLVM. It looks like we will be more than able to build the new Mesa and LLVM
<alyssa>
DemiMarie: For context, AMD provides an OpenGL driver in Mesa (radeonsi) that depends on their compiler in upstream LLVM.
<DemiMarie>
alyssa: yeah, saw about that w.r.t. NIR
<alyssa>
Independently, the Mesa community (mostly backed by Valve, not really backed by AMD) provides a Vulkan driver in Mesa (radv) that uses our own compiler (ACO) in Mesa -- no LLVM involved.
<alyssa>
So if you could use aco (either directly via radeonsi or indirectly via radv with zink to layer GL-on-Vulkan) you can cut the "we need LLVM for AMD" issue out of the loop
<alyssa>
You're still left with the "softpipe is extremely slow" which means without LLVM and without a GPU (supported in Mesa) you're extremely slow
<alyssa>
but that doesn't apply for new hardware support, so maybe you could have a mesa-llvmpipe-and-pre-2012-radeonsi package separate from mesa-everything else, where the former is an old version of Mesa with an old version of LLVM, and the latter is a new version of Mesa without any LLVM?
<alyssa>
and then switch between the two with GLVND at runtime so they can coexist?)
<alyssa>
(the old version of Mesa being the amber branch, presumably)
<alyssa>
that way you can upgrade Mesa for new hardware without needing to upgrade the LLVM for the old hardware
<alyssa>
I don't know what qubes packaging looks like to know if that's workable
<alyssa>
for Debian I think it could be made to work
<alyssa>
this is all predicated on having a sane way to run an LLVM-free AMD GL implementation
<alyssa>
in theory radeonsi+aco existed on some downstream branch somewhere, and in theory zink+radv is a thing, but neither is production tested AFAIK
<alyssa>
and IDK if your desperate need to avoid unwanted LLVM uprevs is burning enough to test those in production
<alyssa>
for Arm Mali and Apple GPUs, we're running LLVM-free Mesa and it works fine
<alyssa>
the AMD scene is out of my area though
<alyssa>
I kinda want to play with a qbepipe or mirpipe or craneliftpipe at some point
pcercuei has quit [Quit: dodo]
<alyssa>
qbe is deliberately limited in optimizer power compared to llvm, but in all my hubris I feel like NIR's optimizer is so good that it shouldn't matter ;)
<alyssa>
i might just like that it's an ssa-based ra :p
Haaninjo has quit [Quit: Ex-Chat]
<DemiMarie>
What limits how fast software renderers can be?
<DemiMarie>
Modern CPUs have really powerful SIMD units. Is there something that prevents those from being brought to bear?
<HdkR>
They aren't wide enough and don't have specialized hardware that GPUs have. Larrabee is a testimate to that problem.
<DemiMarie>
What specialized hardware are you referring to?
<HdkR>
rops, texture fetch units, 1TB/s memory bandwidth, RT units now :P
<DemiMarie>
RT?
<HdkR>
ray-tracing
<DemiMarie>
Memory bandwidth doesn’t count because I am only trying to compete with small iGPUs
<HdkR>
But really, domain specific hardware optimizations beat out a general solution on the CPU side, it'll never compete realistically.
<DemiMarie>
I know that much
<DemiMarie>
But I have also heard that llvmpipe is unoptimized in certain ways
<DemiMarie>
Will matrix extensions help some?
<HdkR>
llvmpipe gets bounded up by vertex side a lot doesn't it? Something that SWR tried addressing?
<airlied>
alyssa: pretty sure the asahi has llvmpipe
<airlied>
DemiMarie: memory bandwidth is the biggest bottleneck on swrast
<airlied>
HdkR: not really
<airlied>
I fixed a bit of that and most desktopy apps aren't in any way vertex heavy
<DemiMarie>
airlied: does an i915 have any more memory bandwidth than the CPU next to it?
<airlied>
DemiMarie: yes
<airlied>
particularly around tiling patterns and cache interactions
<HdkR>
airlied: Ah neat, didn't know if it had improvements since last I looked. I'm usually bottlenecked by other things :P
natto has quit []
<kisak>
lstrano_: thanks for the heads up. Unfortunately, the timeline for that is some time in the next 6 months.
<airlied>
HdkR: yeah it can at least overlap vs and fs operations now, heaven can saturate my cpu cores
<airlied>
I think parallising binning would be the next biggest thing that could be done for vertex heavy workloads
natto has joined #dri-devel
natto has quit []
natto has joined #dri-devel
marmarek[m] has joined #dri-devel
<HdkR>
airlied: Sounds like a good time :D
CATS has quit [Server closed connection]
CATS has joined #dri-devel
natto has quit []
natto has joined #dri-devel
natto has quit []
natto has joined #dri-devel
<airlied>
HdkR: avx512 would be a better time :-P
<clever>
HdkR: "They aren't wide enough", is that in terms of how many ops it can do in parallel, or in terms of bits per register?
Adrinael has quit [Server closed connection]
Adrinael has joined #dri-devel
<clever>
for (int i=0; i<16; i++) { int temp = a[i] * b[i]; if (store) c[i] = temp; if (accumulate) accumulator[i] += temp; }
natto has quit []
<clever>
HdkR: the rpi has a hardware block that can do this entire operation in 2 clock cycles back 2 back, up to 64 times in a row, but a/b are limited to 16bit ints, temp/c can be up to 32bits, and accumulator is 48bits
natto has joined #dri-devel
<jenatali>
Demi: fwiw we statically link on Windows, but the Windows runtime loader/linker doesn't have the same interposition problems you get on Linux distros
Guest1883 has quit [Server closed connection]
immibis_ has joined #dri-devel
marcan has quit [Server closed connection]
marcan has joined #dri-devel
paulk-bis has joined #dri-devel
yuq825 has joined #dri-devel
paulk has quit [Read error: Connection reset by peer]
<DemiMarie>
jenatali: yeah Windows does dynamic linking far better than \*nix
llyyr has quit [Server closed connection]
llyyr has joined #dri-devel
LaserEyess has quit [Server closed connection]
<DemiMarie>
clever: what is that operation used for?
<clever>
DemiMarie: ive implemented a FIR filter with it
<clever>
DemiMarie: the official firmware i think does some FFT's with it
<clever>
oh, and one guy made a mandelbrot with it
<DemiMarie>
clever: is that just an arbitrary operation or is there something special about it?
ybogdano has quit [Ping timeout: 480 seconds]
Leopold_ has quit [Remote host closed the connection]
LaserEyess has joined #dri-devel
<clever>
DemiMarie: the special bit, is that its able to do 16 operations in parallel
Leopold_ has joined #dri-devel
<clever>
DemiMarie: so if you have a lot of math you need to do, these vector opcodes can do it
yogesh_mohan has joined #dri-devel
<DemiMarie>
clever: what do you mean by “up to 64 times in a row”?
<DemiMarie>
also, thoughts on matrix extensions?
<clever>
DemiMarie: basically, you can give it an uint16_t foo[n][16]; where n is in the range of 1 to 64
<clever>
and it will do 16 operations every 2 clock cycles
marex has quit [Server closed connection]
marex has joined #dri-devel
<clever>
in the case of a FIR filter, you would give it 2 such arrays, `int16_t foo[64][16]; int16_t bar[64][16];` and then the VPU can multiply every element and sum them together
<clever>
so its basically the same as: for (int i=0; i<1024; i++) { accumulator += a[i] * b[i]; }
<DemiMarie>
Would be nice to have a sandboxing compiler that targeted the VPU, since the VPU has no MMU or other isolation features.
<clever>
but it can run that entire 1024 mults and accumulate, in just 128 clock cycles
<DemiMarie>
Wasn’t the VPU (a Hexagon DSP with HVX, IIRC) originally intended to be the main processor, with the ARM cores used for other tasks?
<clever>
yep
<clever>
the VPU also has a set of sandbox registers
<clever>
i suspect it acts similar to a cortex-m MPU
any1 has quit [Server closed connection]
<clever>
where accessing an address outside the allowed ranges will fault
<alyssa>
granted this is also an unreleased dev branch but err
<clever>
DemiMarie: the rest is just notes ive made as i try to make sense of that
<DemiMarie>
I don’t think Qubes will be stuck with software rendering forever
Ziemas has quit [Server closed connection]
Ziemas has joined #dri-devel
<airlied>
alyssa: no gpu for mere mortals yet
<airlied>
karolherbst: does test_compiler work for you?
* airlied
is getting a spir-v error
jcristau has quit [Server closed connection]
jcristau has joined #dri-devel
<karolherbst>
yeah
<karolherbst>
you need an updated spirv-tools tho
<jenatali>
karolherbst: airlied : have either of you tried using the SPIR-V backend in Clang instead of the SPIRV-LLVM-Translator?
<karolherbst>
v2022.3 at least
<karolherbst>
no
<karolherbst>
and I probably won't try before llvm-17
<jenatali>
Fair enough
<karolherbst>
or well.. I'll try once intel uses it :)
<airlied>
karolherbst: oh let try a newer spirv-tools
<jenatali>
Someone involved in SYCL mentioned they're using it with the CL SPIR-V extension and it works, where I don't think the translator does. I'm curious what the point of the translator is now
<karolherbst>
maybe because I force it being a GPU?
<airlied>
shouldn't matter I don't think for those
<karolherbst>
just try it?
<airlied>
like it's not about the operation, it's the result that is wierd
<karolherbst>
yeah...
<airlied>
the results are correct just not expected
<airlied>
the sampler repeat fails are kinda funky, I think I can fix one set of them
<airlied>
just not sure if it's something we want to fix
<airlied>
the overhead might be a bit too much for non-cts cases
<karolherbst>
yeah...
<karolherbst>
ignore the non nearest one
<karolherbst>
ehh wait
<karolherbst>
those are different fails
<karolherbst>
anyway.. the spir-v issue I've hit got resolved, so I'll merge that MR soon :)
<airlied>
karolherbst: got the discord server invite btw?
* airlied
might be able to create an account again
<karolherbst>
check out #rusticl
<karolherbst>
should be there
<airlied>
let's see how long I last this time
<alyssa>
airlied: karolherbst: jenatali: can I get one of you to review the first patch of !19996?
<alyssa>
it's short
<jenatali>
alyssa: did you mean me or jekstrand?
<alyssa>
jenatali: you're a NIR reviewer, right?
<alyssa>
this is how we get you ;p
<karolherbst>
this sign extend stuff feels a but cursed, but yeah...
<alyssa>
karolherbst: the alternative is having 2x the intrinsics..
<jenatali>
I mean I can review, just didn't seem relevant
<jenatali>
But not tonight
<karolherbst>
alyssa: yeah.. it's fine
zf_ has joined #dri-devel
zf has quit [Read error: Connection reset by peer]
<alyssa>
karolherbst: is that an acked-by
<karolherbst>
yeah
<alyssa>
great assigning to marge
<alyssa>
jenatali: you're off the hook, procastination to the resuce
<alyssa>
rescue
<jenatali>
\o/
turol has quit [Server closed connection]
turol has joined #dri-devel
<alyssa>
let's see if it'll get through "it touches common code" CI ;p
<jenatali>
Good luck
<alyssa>
it looks like CI is currently dead so "probably no"
jadahl has quit [Server closed connection]
jadahl has joined #dri-devel
kgz has quit [Server closed connection]
<jenatali>
I managed to get one through right before it went down I guess
kgz has joined #dri-devel
shadeslayer has quit [Server closed connection]
<jenatali>
I don't suppose anyone wants to review !20102
heat has quit [Ping timeout: 480 seconds]
calebccff has quit [Server closed connection]
calebccff has joined #dri-devel
Plagman has quit [Server closed connection]
Plagman has joined #dri-devel
shadeslayer has joined #dri-devel
shadeslayer is now known as Guest614
mhenning has quit [Quit: mhenning]
<airlied>
karolherbst: so contractions is failing due to I think x87 vs sse multiplies
<alyssa>
airlied: can't! don't! won't!
* airlied
is glad I worked it out 15 minutes before my xmas party and beer
<airlied>
maybe by tomorrow I'll have forgotten it again
<airlied>
hmm cl cts claims it should be using fpmath=sse though
<airlied>
okay if it's not that then I really need a drink
dos11 has quit [Server closed connection]
dos1 has joined #dri-devel
<karolherbst>
airlied: sounds plausible
<airlied>
wierd mulss in the asm, now I'm extra confused
aravind has joined #dri-devel
emersion has quit [Server closed connection]
emersion has joined #dri-devel
<airlied>
1.57062e-13 * 3.76992e-32 is coming out as 0
<alyssa>
airlied: llvmpipe cl?
<alyssa>
zink+lavapipe?
<airlied>
alyssa: yah llvmpipe cl, though this is CTS code generating the values
<airlied>
it must be some round to zero denormal bs
urja has quit [Ping timeout: 480 seconds]
<karolherbst>
alyssa: maybe some funky denorm stuff?
<karolherbst>
ehh...
<karolherbst>
airlied: ^^
<airlied>
okay tests pass with -z to the test
<airlied>
so rusticl/llvmpipe might be misreporting something
<karolherbst>
yeah.. it's always reporting not supporting denorms
<airlied>
in the floatCapabilties
<airlied>
okay that might it then
<karolherbst>
denorms are quite in a sad state in mesa atm
Ristovski has quit [Server closed connection]
<airlied>
obv not in llvmpipe since it passes :-P
Ristovski has joined #dri-devel
<karolherbst>
and if somebody wants to clean it all up, then yeah, would be helfpful, but the problematic part is lowering code
<karolherbst>
well
<karolherbst>
yes
<karolherbst>
it causes issues in other places
<karolherbst>
though llvmpipe might actually be fine.. dunno
<airlied>
I suppose I could just turn them off for llvmpipe
<karolherbst>
this will all become a huge pita once we want to advertise fp64
vup has quit [Server closed connection]
vup has joined #dri-devel
<airlied>
ah cool contractions is all good with -z
<airlied>
one less mystery
<karolherbst>
yeah...
<karolherbst>
something is odd with the vector stuff.. dunno
<karolherbst>
ohh
<karolherbst>
it was alignment stuff
<karolherbst>
that's for you to fix :P
<karolherbst>
some buffers need 0x100 instead of 0x80 alignment or something funky like that
<jenatali>
karolherbst: What's the problem with fp64?
<karolherbst>
it requires denorms
<jenatali>
Right, but I thought that hardware that has fp64 support has fp64 denorm support
<karolherbst>
yeah well..
<jenatali>
I thought it was just fp32 denorms that were weird
<karolherbst>
all the cl builtins also need proper denorm support
<jenatali>
Yeah, and?
<karolherbst>
yeah dunno.. it causes issues once your hardware doesn't support it all
<karolherbst>
and our fp64 emulation doesn't handle denorms anyway
<jenatali>
Seems like you shouldn't report fp64 if you don't support it at all :P
<karolherbst>
yeah, well.. I don't :)
<jenatali>
Unlike GL where it's on the critical path to supporting new GL versions, it's always-optional in CL
<karolherbst>
yeah...
<karolherbst>
but some might want to see fp64 being enabled sooner or later
<jenatali>
I can't enable it for D3D because we're missing rounding instructions in fp64 :(
<karolherbst>
:/
ana has quit [Server closed connection]
ana has joined #dri-devel
Jeremy_Rand_Talos_ has quit [Remote host closed the connection]
Jeremy_Rand_Talos_ has joined #dri-devel
libv has quit [Server closed connection]
libv has joined #dri-devel
alyssa has left #dri-devel [#dri-devel]
CME has quit [Server closed connection]
CME has joined #dri-devel
aravind has quit [Remote host closed the connection]
aravind has joined #dri-devel
qyliss has quit [Server closed connection]
qyliss has joined #dri-devel
frytaped has joined #dri-devel
xantoz has quit [Server closed connection]
xantoz has joined #dri-devel
ickle has quit [Server closed connection]
ickle has joined #dri-devel
sigmaris has quit [Server closed connection]
sigmaris has joined #dri-devel
Guest1030 has quit [Server closed connection]
dreda has joined #dri-devel
dreda is now known as Guest630
frytaped has quit [Quit: WeeChat 3.6]
frytaped has joined #dri-devel
frytaped has quit []
lplc has quit [Ping timeout: 480 seconds]
frytaped has joined #dri-devel
Akari has joined #dri-devel
frytaped has quit []
frytaped has joined #dri-devel
frytaped has quit []
Daanct12 has joined #dri-devel
bmodem has joined #dri-devel
lplc has joined #dri-devel
Akari has quit [Quit: segmentation fault (core dumped)]
Duke`` has joined #dri-devel
lina_ has quit []
lina has joined #dri-devel
LordKalma has quit [Server closed connection]
LordKalma has joined #dri-devel
zamundaaa has quit [Server closed connection]
ivyl has quit [Server closed connection]
ivyl has joined #dri-devel
loki_val has quit [Server closed connection]
crabbedhaloablut has joined #dri-devel
Namarrgon has quit [Server closed connection]
Namarrgon has joined #dri-devel
camus has joined #dri-devel
camus has quit []
camus has joined #dri-devel
camus has quit []
Stary has quit [Server closed connection]
Stary has joined #dri-devel
camus has joined #dri-devel
zamundaaa has joined #dri-devel
Scorpi has quit [Server closed connection]
Scorpi has joined #dri-devel
Thaodan has quit [Server closed connection]
Thaodan has joined #dri-devel
Daanct12 has quit [Quit: Quitting]
kts has joined #dri-devel
fab has joined #dri-devel
itoral has joined #dri-devel
oneforall2 has joined #dri-devel
Duke`` has quit [Ping timeout: 480 seconds]
DPA has quit [Server closed connection]
DPA has joined #dri-devel
Leopold_ has quit [Ping timeout: 480 seconds]
bmodem1 has joined #dri-devel
tomba has quit [Server closed connection]
tomba has joined #dri-devel
dcbaker has quit [Server closed connection]
dcbaker has joined #dri-devel
bmodem has quit [Ping timeout: 480 seconds]
Wallbraker has quit [Server closed connection]
Wallbraker has joined #dri-devel
bgs has joined #dri-devel
bgs has quit [Remote host closed the connection]
eballetbo has quit [Server closed connection]
eballetbo has joined #dri-devel
marmarek[m] has quit [Server closed connection]
marmarek[m] has joined #dri-devel
kusma has quit [Server closed connection]
kusma has joined #dri-devel
mairacanal[m] has quit [Server closed connection]
mairacanal[m] has joined #dri-devel
frytaped has joined #dri-devel
frytaped is now known as godvino
godvino has quit []
bmodem1 has quit [Ping timeout: 480 seconds]
frytaped has joined #dri-devel
heftig has quit [Server closed connection]
heftig has joined #dri-devel
alanc has quit [Remote host closed the connection]
alanc has joined #dri-devel
fab has quit [Quit: fab]
Company has quit [Quit: Leaving]
junaid has joined #dri-devel
danvet has joined #dri-devel
tursulin has joined #dri-devel
tzimmermann has joined #dri-devel
mvlad has joined #dri-devel
vliaskov has joined #dri-devel
djbw has quit [Read error: Connection reset by peer]
hansg has joined #dri-devel
<tomba>
What is the byte order with Y210 format? The drm_fourcc.h comment says "little endian per 2 Y pixels", what does that mean?
dcz_ has joined #dri-devel
lynxeye has joined #dri-devel
jkrzyszt has joined #dri-devel
Guest533 has quit [Server closed connection]
enick_737 has joined #dri-devel
Jean[m]1 has quit [Server closed connection]
Jean[m]1 has joined #dri-devel
hansg has quit [Quit: Leaving]
pcercuei has joined #dri-devel
swalker_ has joined #dri-devel
swalker_ is now known as Guest664
swalker__ has joined #dri-devel
ayaka_ has quit [Quit: Leaving]
Guest664 has quit [Ping timeout: 480 seconds]
Jeremy_Rand_Talos__ has joined #dri-devel
Jeremy_Rand_Talos_ has quit [Remote host closed the connection]
heat has joined #dri-devel
Leopold_ has joined #dri-devel
devilhorns has joined #dri-devel
urja has joined #dri-devel
aravind has quit [Ping timeout: 480 seconds]
Guest614 is now known as shadeslayer
hansg has joined #dri-devel
junaid has quit [Ping timeout: 480 seconds]
darkbasic has joined #dri-devel
darkbasic is now known as darkbasic4
Dylanger has quit [Server closed connection]
Dylanger has joined #dri-devel
Haaninjo has joined #dri-devel
itoral has quit []
hansg has quit [Quit: Leaving]
frytaped is now known as Guest679
enick_737 is now known as frytaped
frytaped is now known as go4godvin
Guest679 has quit []
frytaped has joined #dri-devel
frytaped is now known as Guest681
Guest681 is now known as frytaped
frytaped has quit []
frytaped has joined #dri-devel
kts has quit [Quit: Leaving]
kts has joined #dri-devel
bgs has joined #dri-devel
bgs has quit [Remote host closed the connection]
kts has quit [Quit: Leaving]
<dwlsalmeida>
btw I want to give some feedback to the people that helped me when I asked about fixing vaQuerySurfaceStatus and vaSyncSurface, the suggestion of using a fence worked fine, thanks!
<MrCooper>
ajax DemiMarie: radeonsi (the Mesa driver for all AMD GPUs since ~10 years ago) requires LLVM, the drivers for older AMD GPUs don't (anymore)
Leopold_ has quit [Remote host closed the connection]
off^ has quit [Ping timeout: 480 seconds]
yuq825 has left #dri-devel [#dri-devel]
zehortigoza has quit [Remote host closed the connection]
Leopold_ has joined #dri-devel
<dj-death>
is there a way to identify array access of something like this in NIR? : in gl_PerVertex { ... } gl_in[]
<dj-death>
looking to limit accesses to that gl_in[] array to a max index
<jenatali>
Before/without lowered I/O?
<dj-death>
I can't find a way to identify it coming out of spirv
<dj-death>
I can do before the deref lowering
<dj-death>
or later
<emersion>
jekstrand: when importing a DMA-BUF into vulkan, do i need to explicitly wait on the DMA-BUF shared fence?
zehortigoza has joined #dri-devel
<jenatali>
If you're doing it after, it's easier, since it'll be a per_vertex load intrinsic. You can just clamp the vertex source
zzoon[m] has quit [Server closed connection]
zzoon[m] has joined #dri-devel
sjfricke[m] has quit [Server closed connection]
sjfricke[m] has joined #dri-devel
<dj-death>
jenatali: thanks
<dj-death>
jenatali: yeah I see nir_intrinsic_load_per_vertex_input
<jenatali>
Yeah I don't remember which source is the vertex off the top of my head, but should be easy enough to just insert a max() on that source
fab has joined #dri-devel
<dj-death>
source 0 apparently
<emersion>
jekstrand: sounds like waiting fixes flickering on intel, but is not necessary on amd
Company has joined #dri-devel
ella-0[m] has quit [Server closed connection]
ella-0[m] has joined #dri-devel
gdevi has quit [Server closed connection]
gdevi has joined #dri-devel
jasuarez has quit [Server closed connection]
jasuarez has joined #dri-devel
kunal_1072002[m] has quit [Server closed connection]
kunal_1072002[m] has joined #dri-devel
KunalAgarwal[m][m] has quit [Server closed connection]
KunalAgarwal[m][m] has joined #dri-devel
moben[m] has quit [Server closed connection]
moben[m] has joined #dri-devel
naheemsays[m] has quit [Server closed connection]
naheemsays[m] has joined #dri-devel
undvasistas[m] has quit [Server closed connection]
undvasistas[m] has joined #dri-devel
Soroush has quit [Server closed connection]
Soroush has joined #dri-devel
znullptr[m] has quit [Server closed connection]
znullptr[m] has joined #dri-devel
<dj-death>
jenatali: thanks a lot that works :)
<jenatali>
👍
mbrost has joined #dri-devel
zarast has joined #dri-devel
tursulin has quit [Ping timeout: 480 seconds]
zaratustra has quit [Ping timeout: 480 seconds]
Duke`` has joined #dri-devel
junaid has joined #dri-devel
zarast has quit [Ping timeout: 480 seconds]
zarast has joined #dri-devel
ybogdano has joined #dri-devel
junaid has quit [Remote host closed the connection]
<MrCooper>
emersion: FWIW, it makes sense to me that you'd need to explicitly wait, since Vulkan wants to be explicit about everything; I suspect RADV just can't disable implicit sync yet
djbw has joined #dri-devel
alyssa has joined #dri-devel
<alyssa>
...is f2i32(ffloor(x)) different than just f2i32(x)?
<alyssa>
like, f2i32 is rtz anyway, right..?
<alyssa>
oh, they differ for negative x. ok
<alyssa>
"f2i32_rtn" I guess
<emersion>
MrCooper: yeah that makes sense
alyssa has left #dri-devel [#dri-devel]
ybogdano is now known as Guest701
Guest701 has quit [Read error: Connection reset by peer]
ybogdano has joined #dri-devel
<jekstrand>
emersion: Generally, yes, I think.
<jekstrand>
emersion: More to the point, the Vulkan driver won't do any implicit waiting for you.
<jekstrand>
Or any implicit signaling
<jekstrand>
(it may be the signaling that's missing on AMD)
<emersion>
ok, thanks
<emersion>
AMD works fine, Intel doesn't
<emersion>
may be related to all the work you've been doing to remove waits and implicit sync in anv
<karolherbst>
maybe it's fine like that for now? mhh
<kisak>
jenatali: morning, I got lucky and found that https://gitlab.freedesktop.org/mesa/mesa/-/commit/f9057cea517e01e05f08f00a741aad5bae154d62 is what broke d3d12/dozen on bionic. Short term I can slip "confflags_GALLIUM += -Dcpp_std=c++14" into the debian packaging, but that's not going to last for more than a release series or two or when llvm 16 rolls around
<kisak>
(mesa is built with gcc 7.5.0 on bionic)
<jenatali>
Ooh, cool
eukara has joined #dri-devel
rgallaispou has quit [Read error: Connection reset by peer]
swalker__ has quit [Remote host closed the connection]
Jeremy_Rand_Talos__ has quit [Remote host closed the connection]
Jeremy_Rand_Talos has joined #dri-devel
gouchi has joined #dri-devel
rasterman has joined #dri-devel
jfalempe_ has quit []
vliaskov has quit [Ping timeout: 480 seconds]
ybogdano has quit [Read error: Connection reset by peer]
devilhorns has quit []
luc4 has joined #dri-devel
rmckeever has joined #dri-devel
mhenning has joined #dri-devel
Akari has joined #dri-devel
Leopold_ has quit [Remote host closed the connection]
Leopold_ has joined #dri-devel
cheako has quit [Quit: Connection closed for inactivity]
pcercuei has quit [Read error: Connection reset by peer]
pcercuei has joined #dri-devel
lynxeye has quit [Quit: Leaving.]
cheako has joined #dri-devel
srslypascal is now known as Guest708
srslypascal has joined #dri-devel
Guest708 has quit [Ping timeout: 480 seconds]
gouchi has quit [Quit: Quitte]
ybogdano has joined #dri-devel
<jenatali>
jekstrand: When you get a chance I'd love a re-review of !16200 (DXGI swapchains for dzn). I think it's good
heat has quit [Remote host closed the connection]
heat has joined #dri-devel
tzimmermann has quit [Quit: Leaving]
luc4 has quit [Ping timeout: 480 seconds]
pcercuei has quit [Quit: brb]
pcercuei has joined #dri-devel
mbrost has quit [Ping timeout: 480 seconds]
HerrSpliet has joined #dri-devel
RSpliet has quit [Ping timeout: 480 seconds]
mbrost has joined #dri-devel
fab has quit [Quit: fab]
ybogdano has quit [Read error: Connection reset by peer]
fab has joined #dri-devel
jkrzyszt has quit [Remote host closed the connection]
ybogdano has joined #dri-devel
RSpliet has joined #dri-devel
Jeremy_Rand_Talos has quit [Remote host closed the connection]
Jeremy_Rand_Talos has joined #dri-devel
HerrSpliet has quit [Ping timeout: 480 seconds]
danvet has quit [Read error: No route to host]
Leopold_ has quit [Remote host closed the connection]
darkbasic4 has quit [Remote host closed the connection]
mbrost has quit [Ping timeout: 480 seconds]
<Jeremy_Rand_Talos>
What's the right way to get an apitrace recording of Plasma shell? Some quick DuckDuckGoinng suggests that the standard way to do it is "apitrace trace plasmashell --replace", but AFAICT that yields a very small trace file that shows 0 frames when replayed. Not sure if I'm doing something obviously wrong or if maybe there's a non-obvious trick.
<Jeremy_Rand_Talos>
Also more generally, if a trace shows 0 frames when replayed, is that indicative of any particular issue?
<Jeremy_Rand_Talos>
I also tried tracing GNOME Maps, and that yielded a nice big 300MB trace, but it also shows 0 frames when replayed
junaid has joined #dri-devel
dcz_ has quit [Ping timeout: 480 seconds]
luc4 has joined #dri-devel
junaid has quit [Ping timeout: 480 seconds]
mbrost has joined #dri-devel
mvlad has quit [Remote host closed the connection]
Duke`` has quit [Ping timeout: 480 seconds]
mareko has quit [Remote host closed the connection]