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
<alyssa> personally I run Debian testing
<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
columbarius has joined #dri-devel
<clever> that can kinda solve the lack of MMU
any1 has joined #dri-devel
co1umbarius has quit [Ping timeout: 480 seconds]
<clever> this is using vector opcodes to render the mandelbrot
<clever> after some more optimization, i think i got it down to 90ms per frame
<clever> i think the biggest thing that is missing right now, is a compiler that supports the vector opcodes
<alyssa> airlied: notice I said Apple /GPUs/ ;-p
<airlied> alyssa: Apple CPUs with llvmpipe are good GPUs :-P
<alyssa> airlied: Accurate lol
<alyssa> well, I have a better GPU ;p
<DemiMarie> airlied: are you serious when you say that? As in, comparable to an Intel iGPU?
<alyssa> m1 go brrrrrgh
rawoul has quit [Server closed connection]
rawoul has joined #dri-devel
<airlied> intel igpus have gotten a lot better, but maybe compared to a few gens ago
heat has quit [Remote host closed the connection]
heat has joined #dri-devel
<Lynne> a few gens ago they were beyond horrible
<Lynne> 4k laptops were just starting to appear
<DemiMarie> clever: can you provide some links to documentation?
<DemiMarie> airlied: are you saying that one could run GNOME on M1 with just software rendering and it would be reasonably responsive?
<Lynne> and all their hardware was capable of was a pixel rate which would be shamed from someting from 15 years ago
<airlied> DemiMarie: I think people have been doing that, since therer is no GPU support yet
<alyssa> DemiMarie: Yes, I did that for a while
<alyssa> airlied: Disagree hello from GNOME on M1 with GPU accel
<alyssa> stupidly smooth animations argh
<alyssa> :-p
<clever> DemiMarie: https://github.com/hermanhermitage/videocoreiv/wiki/VideoCore-IV-Programmers-Manual is the main source of documentation
<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> jenatali: I don't think that's true though?
<karolherbst> one from intel said to me on tuesday they still use the translator
<jenatali> Interesting
<karolherbst> _but_ the spirv I get from intels sycl impl is also invalid, soo...
<airlied> yeah I don't think it's quite there yet
<karolherbst> they might do funky things there
V has quit [Server closed connection]
V has joined #dri-devel
<airlied> karolherbst: I had some math fails isfinite/isnormal/signbit
<jenatali> He said Clang master, not stable, so I guess it's not quite done yet, yeah
<karolherbst> ahh
<karolherbst> figures
<karolherbst> airlied: no idea.. should work? dunno
<airlied> yay updated spirv-tools fixed compiler
<karolherbst> still busy with upstreaming radeonsi support, in case you want to help: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19855
<airlied> karolherbst: the math fails are all the returns 1 for scalar vs -1 for vector problem
<karolherbst> for the most silly reasons I need this for radeonsi
<karolherbst> airlied: ehhh....
<airlied> no idea why you aren't hitting that though
<airlied> maybe spirv-llvm-translator update required
<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)
camus has quit [Ping timeout: 480 seconds]
zaratustra has quit [Ping timeout: 480 seconds]
zaratustra has joined #dri-devel
heat has quit [Read error: No route to host]
heat has joined #dri-devel
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]
Leopold_ has joined #dri-devel
fab has quit [Quit: fab]
agd5f has joined #dri-devel
danvet has joined #dri-devel
agd5f has quit [Read error: No route to host]
agd5f has joined #dri-devel
Thaodan has quit [Quit: ZNC - https://znc.in]
Thaodan has joined #dri-devel
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]
mareko has joined #dri-devel
rmckeever has quit [Quit: Leaving]
rasterman has quit [Quit: Gettin' stinky!]
danvet has quit [Ping timeout: 480 seconds]
mhenning has quit [Quit: mhenning]
tanty has quit []
tanty has joined #dri-devel
tanty has quit []
fxkamd has quit []
tanty has joined #dri-devel
anholt_ has joined #dri-devel
anholt has quit [Ping timeout: 480 seconds]
mbrost has quit [Ping timeout: 480 seconds]
Haaninjo has quit [Quit: Ex-Chat]