ChanServ changed the topic of #dri-devel to: <ajax> nothing involved with X should ever be unable to find a bar
fxkamd has quit []
fxkamd has joined #dri-devel
fxkamd has quit []
sassefa has quit [Quit: sassefa]
sassefa has joined #dri-devel
benjaminl has quit [Ping timeout: 480 seconds]
co1umbarius has joined #dri-devel
columbarius has quit [Ping timeout: 480 seconds]
benjaminl has joined #dri-devel
Danct12 is now known as Guest2769
Danct12 has joined #dri-devel
YuGiOhJCJ has joined #dri-devel
<kode54> btw
<kode54> that issue I reported for flickering water layer in Borderlands 3?
<kode54> I replicated it in Borderlands 2
<kode54> I'll post as such in the issue
<kode54> easier to get to it there, you don't have to watch any benchmark
<kode54> you can just left-click and pan the view around to look at the lake in the valley below
heat has joined #dri-devel
heat_ has quit [Read error: Connection reset by peer]
camus has quit [Ping timeout: 480 seconds]
benjaminl has quit [Ping timeout: 480 seconds]
sassefa has quit [Remote host closed the connection]
camus has joined #dri-devel
camus1 has joined #dri-devel
camus has quit [Ping timeout: 480 seconds]
Company has quit [Quit: Leaving]
heat has quit [Ping timeout: 480 seconds]
bmodem has joined #dri-devel
TMM has quit [Quit: https://quassel-irc.org - Chat comfortably. Anywhere.]
TMM has joined #dri-devel
Danct12 has quit [Quit: WeeChat 3.8]
guru_ has quit []
oneforall2 has joined #dri-devel
jewins has quit [Ping timeout: 480 seconds]
benjaminl has joined #dri-devel
kzd has quit [Ping timeout: 480 seconds]
tzimmermann has joined #dri-devel
benjaminl has quit [Ping timeout: 480 seconds]
fab has joined #dri-devel
bgs has joined #dri-devel
JohnnyonFlame has joined #dri-devel
jkrzyszt has joined #dri-devel
Leopold__ has joined #dri-devel
sima has joined #dri-devel
Leopold_ has quit [Ping timeout: 480 seconds]
lyudess has joined #dri-devel
alanc has quit [Remote host closed the connection]
alanc has joined #dri-devel
Lyude has quit [Ping timeout: 480 seconds]
fab has quit [Quit: fab]
sghuge has quit [Remote host closed the connection]
sghuge has joined #dri-devel
benjaminl has joined #dri-devel
jfalempe has joined #dri-devel
benjaminl has quit [Quit: WeeChat 3.8]
tursulin has joined #dri-devel
fab has joined #dri-devel
frankbinns1 has joined #dri-devel
smiles_ has quit [Ping timeout: 480 seconds]
frankbinns has joined #dri-devel
frankbinns2 has joined #dri-devel
frankbinns1 has quit [Ping timeout: 480 seconds]
frankbinns has quit [Ping timeout: 480 seconds]
<pq> emersion, I read your reply on the KMS color pipeline thread, and I agree with everything your wrote.
pochu has joined #dri-devel
camus1 has quit [Read error: Connection reset by peer]
camus has joined #dri-devel
JohnnyonFlame has quit [Ping timeout: 480 seconds]
<emersion> pq, sweet!
lynxeye has joined #dri-devel
smiles_ has joined #dri-devel
swalker_ has joined #dri-devel
swalker_ is now known as Guest2793
swalker__ has joined #dri-devel
Guest2793 has quit [Ping timeout: 480 seconds]
anarsoul|2 has joined #dri-devel
anarsoul has quit [Read error: No route to host]
xroumegue has joined #dri-devel
camus1 has joined #dri-devel
camus has quit [Read error: Connection reset by peer]
camus has joined #dri-devel
camus1 has quit [Remote host closed the connection]
jewins has joined #dri-devel
jewins has quit [Ping timeout: 480 seconds]
oneforall2 has quit [Remote host closed the connection]
oneforall2 has joined #dri-devel
pochu has quit [Quit: leaving]
rsalvaterra has quit []
rsalvaterra has joined #dri-devel
Danct12 has joined #dri-devel
pochu has joined #dri-devel
Danct12 has quit [Ping timeout: 480 seconds]
rasterman has joined #dri-devel
Leopold__ has quit [Remote host closed the connection]
Leopold_ has joined #dri-devel
robmur01 has quit [Remote host closed the connection]
JohnnyonFlame has joined #dri-devel
robmur01 has joined #dri-devel
pochu has quit [Read error: Connection reset by peer]
pochu has joined #dri-devel
bmodem1 has joined #dri-devel
bmodem has quit [Ping timeout: 480 seconds]
Piraty has quit [Remote host closed the connection]
Piraty has joined #dri-devel
Piraty has quit []
Piraty has joined #dri-devel
vliaskov has joined #dri-devel
djbw_ has quit [Read error: Connection reset by peer]
kasper93_ is now known as kasper93
FireBurn has joined #dri-devel
heat has joined #dri-devel
<FireBurn> Would someone mind reverting 58e67bb3c131da5ee14e4842b08e53f4888dce0a I'm hoping to avoid it getting sent to airlied and onto linus
<zamundaaa[m]> Is there a way to import an EGL fence?
<zamundaaa[m]> I'm trying to blit a texture from one GPU to another, and with NVIdia that causes artifacts because of the lack of synchronization. Ideally I'd create an EGL fence on the source GPU, and have the other GPU wait before doing the blit with eglWaitSync, but I haven't found a way to actually get a fence for this on the destination GPU
<emersion> look at weston maybe
FireBurn has quit [Ping timeout: 480 seconds]
<pq> EGL_ANDROID_native_fence_sync might be the key
<zamundaaa[m]> ah, so the fd is passed in as an attribute. Thanks!
<ickle> win 16
jewins has joined #dri-devel
<emersion> sad that there's no drm_syncobj love
f11f12 has joined #dri-devel
alyssa has joined #dri-devel
<alyssa> gfxstrand: ok, I have something typed out to kill off abs/neg/fsat modifiers without requiring any nontrivial changes to backends
<alyssa> (in particular, it does not require the backend to have working copyprop or dead code elimination)
<alyssa> I hate it, but more than that I hate that we have backends that don't have DCE
<alyssa> and, it means we actually have a chance of killing them off
<gfxstrand> :sob
<alyssa> so, probably worth the stupid
<alyssa> the usual strategy--
<alyssa> ahead-of-time trivialize pass that inserts copies to ensure fabs/fneg/fsat are folded 100% of the time,
<alyssa> helpers to chase through fabs/fneg/fsat at backend isel time,
<alyssa> and a gaurantee to backends that fabs/fneg/fsat will be chased 100% of the time so they just need to Not emit any code for them
<gfxstrand> Running HSW now
<gfxstrand> Let's see how bad the damage is.
fab has quit [Remote host closed the connection]
<alyssa> from the nir_register changes?
<alyssa> (Intel doesn't use lower_to_source_mods anymore so thankfully it's spared of this particular abomination)
<alyssa> only uses are ntt, etnaviv, a2xx, lima, and r600/sfn
<alyssa> I am not volunteering to rewrite people's compilers
<alyssa> so.. this the consolation prize
<gfxstrand> I'm more worried about vec-to-reg
<alyssa> nod
<alyssa> midgard seems happy with it
<gfxstrand> Okay, ptn bug fixed.
swalker__ has quit [Remote host closed the connection]
kzd has joined #dri-devel
<gfxstrand> I've not done any analysis on why
<gfxstrand> Also, that's vec4-only. I filtered out FS/CS.
zehortigoza has quit [Quit: Coyote finally caught me]
zehortigoza has joined #dri-devel
<alyssa> gfxstrand: :| disappointing
<alyssa> I mean. I would still rip off the bandaid personally, but
<alyssa> midgard was total instructions in shared programs: 1518573 -> 1514188 (-0.29%)
<gfxstrand> I'll look into it this afternoon
<alyssa> I guess what we're seeing here is that Intel has significantly better vec4 copyprop than Midgard and we're getting a regression to the mean
<alyssa> gfxstrand: what's your personal threshold for acceptable shaderdb hit?
nehsou^ has quit [Remote host closed the connection]
hramrach has joined #dri-devel
<hramrach> hello, what card are supported?
FireBurn has joined #dri-devel
<hramrach> RADV page https://docs.mesa3d.org/drivers/radv.html is a stub that point to https://www.x.org/wiki/RadeonFeature/ which has a nice feature table which ends with Arctic Islands. So I suppose for Navi I should turn to Windows?
<pendingchaos> https://www.x.org/wiki/RadeonFeature isn't useful for determining hardware support
<pendingchaos> that feature table isn't about radv
<pendingchaos> apparently it documents radeonsi, but clearly outdated
<hramrach> so what is useful documentation for radv?
<pendingchaos> besides those, it's just a Vulkan driver
<alyssa> gfxstrand: also, pushed nir/legacy-mods, it has your pushed fix squashed in though not the unpushed ptn fix
<hramrach> but that documents driver some diver settings, not what hardware it supports
<pendingchaos> RADV should support all AMD GPUs supporting Vulkan
<hramrach> the moment they are released?
<pendingchaos> there might be some delay (both because of release schedules and development effort) depending on how different the new GPU is from predecessors
<pendingchaos> gfx1100 and gfx1101 for example, should be basically the same
<pendingchaos> gfx1030 and gfx1100 had significant differences
<hramrach> so how do I tell when a GPU has aged enough to be supported?
<llyyr> rdna3 was supported pre-release already
<llyyr> generally stuff should work on release but they might be buggy and that gets sorted out over time
<hramrach> That would be nice improvement since the times that table is from
<pendingchaos> I don't think there's any official list of RADV hardware support, so you can't easily tell
<llyyr> radv supports all GCN/RDNA cards
<pendingchaos> I think usually phoronix and such will release an article when a generation of gpus is supported
<llyyr> so from hd 7000 series up to rx 7xxx
fab has joined #dri-devel
<hramrach> yes, phoronix would probably have that
<pendingchaos> ah, release notes also have new hardware support
<pendingchaos> like https://docs.mesa3d.org/relnotes/22.3.0.html has "Mali T620 on panfrost" and "initial GFX11/RDNA3 support on RADV"
<hramrach> but they are split by version, not by hardware
fxkamd has joined #dri-devel
tzimmermann has quit [Quit: Leaving]
alyssa has left #dri-devel [#dri-devel]
pochu has quit [Quit: leaving]
djbw_ has joined #dri-devel
<mupuf> hramrach: assume everything to work, unless the hardware is really exotic
<mupuf> If it doesn't: file a bug
<mupuf> Generally, the faster GPUs are better supported
<mupuf> Unless they are really expensive
<mupuf> (CDNA cards for example)
<pendingchaos> I don't think RADV works at all on CDNA
<pendingchaos> at least, I don't think the newer ones can support Vulkan
<mupuf> Right :D
tursulin has quit [Ping timeout: 480 seconds]
jkrzyszt has quit [Ping timeout: 480 seconds]
idr has joined #dri-devel
Duke`` has joined #dri-devel
bmodem1 has quit [Ping timeout: 480 seconds]
mbrost has joined #dri-devel
benjaminl has joined #dri-devel
fab has quit [Remote host closed the connection]
<hramrach> so let's say that consumer cards should work, server cards not
<hramrach> thanks
jessica_24 has joined #dri-devel
pcercuei has joined #dri-devel
JohnnyonF has joined #dri-devel
JohnnyonFlame has quit [Ping timeout: 480 seconds]
alyssa has joined #dri-devel
<alyssa> Why is the LLVM IR generated by gallivm so chunky T_T
<alyssa> I guess that includes a big chunk of rasterizer in there too?
caseif has quit [Quit: ZNC 1.8.2+deb2+b1 - https://znc.in]
caseif has joined #dri-devel
YuGiOhJCJ has quit [Quit: YuGiOhJCJ]
caseif has quit [Quit: ZNC 1.8.2+deb3.1 - https://znc.in]
caseif has joined #dri-devel
<DavidHeidelberg[m]> anholt: btw. are the `swrast` runners definitely lost or at some point there is chance in future?
<anholt> they are gone. not going to be standing anything up at least until we have kata.
<agd5f> pendingchaos, you could support vulkan on CDNA cards, but they would only have transfer/compute/media queues, no GFX.
<pendingchaos> didn't the recent CDNA remove texture filtering? I think Vulkan requires that
<pendingchaos> I guess it probably could be emulated with a lot of effort
<pendingchaos> but maybe there's more mandatory Vulkan features that are missing
Duke`` has quit [Ping timeout: 480 seconds]
<agd5f> pendingchaos, should still be supported, at least according to the MI200 ISA document
<agd5f> supports everything needed for OCL 2.x
<pendingchaos> seems to have image_sample
<pendingchaos> no mipmaps though?
<pendingchaos> or gather
<alyssa> agd5f: then why did Marek need to do a software texturing pipeline for CDNA?
Duke`` has joined #dri-devel
<jenatali> gfxstrand, alyssa : Ping on !23173, there's still a few nir patches in there in need of ack/review
smiles_ has quit [Ping timeout: 480 seconds]
<jenatali> :P
<alyssa> the scoped barriers one is only 3 patches left
<jenatali> I suppose that's only fair, I'll take a look
kts has joined #dri-devel
<agd5f> alyssa, maybe it is then? Not sure.
lynxeye has quit [Quit: Leaving.]
stuarts has joined #dri-devel
flibitijibibo has joined #dri-devel
pcercuei has quit [Quit: leaving]
ngcortes has joined #dri-devel
<alyssa> the whole SM5 shift mess is, as usual, a mess
<alyssa> The obviously alternative is changing ubfe_imm to only produce ubfe if lower_bitfield_extract is set, otherwise, ubitfield_extract is produced
<alyssa> s/obviously/obvious/
<alyssa> It's unclear to me if that's better or worse
<alyssa> For the _imm case, ubfe and ubitfield_extract are interchangeable (since we can just mask the immediate at build time)
<alyssa> (or better yet, assert the immediate < 32)
<alyssa> Hmm.. maybe I should do that actually
<alyssa> pendingchaos: thoughts on ^^?
<alyssa> I once again wonder if the default really should be khronos behaviour and _sm5 suffixed ops do the masked thing... meh
<alyssa> would like to kick that can down the road again though.. I just want ubfe_imm or equivalent for agx
Kayden has quit [Quit: -> JF]
benjaminl has quit [Ping timeout: 480 seconds]
Haaninjo has joined #dri-devel
<jenatali> 🤷‍♂️ I looked at it but I don't really have any strong opinions on the matter
digetx is now known as Guest2834
digetx has joined #dri-devel
<alyssa> valid
<alyssa> maybe pendingchaos does
benjaminl has joined #dri-devel
Guest2834 has quit [Ping timeout: 480 seconds]
Kayden has joined #dri-devel
<pendingchaos> I think building ubfe/ubitfield_extract depending on lower_bitfield_extract and using a unified helper makes sense, but having two helpers doesn't sound like a real problem
<alyssa> sure
<alyssa> let me know the preferred bikeshed colour and I'll paint it
kts has quit [Quit: Konversation terminated!]
rasterman has quit [Quit: Gettin' stinky!]
benjaminl has quit [Ping timeout: 480 seconds]
kts has joined #dri-devel
<alyssa> airlied: when you have a few minutes could I pick your brain about AoS/SoA gallivm?
vliaskov has quit []
<alyssa> usually don't like to "ask to ask" but I don't yet have a coherent question formulated
gio_ has joined #dri-devel
<airlied> alyssa: my brain has defeated you by purge AoS/SoA knowledge right down to knowing which one is which
<airlied> but yes ask and pick away
gio has quit [Read error: Connection reset by peer]
<airlied> alyssa: also sampling AoS/SoA is slightly different to the AoS/SoA execution model
<airlied> by default we use soa execution and mostly soa sampling but sometimes sampling goes to aos mode
<airlied> for one narrow use case we use aos execution
kts has quit [Quit: Konversation terminated!]
<alyssa> oh boy
<alyssa> airlied: The basic question I have is that load_reg/store_reg take arrays of LLVMValueRefs
<alyssa> instead of just a single LLVMValueRef for the whole vector
kts has joined #dri-devel
benjaminl has joined #dri-devel
<alyssa> it seems in the AoS path only the [0] component is used
<alyssa> but in the SoA path every component is used separately
<alyssa> I guess "AoS" is like vec4 gpus and "SoA" is like scalar GPUs?
<alyssa> in that case, why would gallivm even see vectorized NIR in the first place?
<alyssa> why not scalarize completely in NIR, so we only need the single LLVMValueRef (corresponding to either the one component or the whole vector)?
<airlied> probably because the core code was originally TGSI designed and TGSI is vec4
<airlied> so it just kept doing that when I ported it to NIR, and handled vecotrs
<airlied> but it doesn't really correspond to GPUs that well
<alyssa> OK
<airlied> SoA mode is it stores 4/8-wide scalars
<airlied> so a vector in SoA mode is just a set of vec-len scalars each of which is 4/8 channels wide
<airlied> depending on avx etc
<alyssa> yes, that's how scalar GPUs work
<airlied> oh my scalar gpus have uniform regs which llvmpipe doesn't :-P
<alyssa> mine don't
<airlied> AoS is a special case for storing 16-wide chars
<airlied> so that you can process 4 8-bit RGBA pixels in one go
<airlied> it's very limited in scope in what you can do
<airlied> it's just to provide a fast path for blits and copies
<alyssa> Right, ok
<airlied> so yes we could probably scalarize completely in NIR for the aos case, but the TGSI code still exists
<alyssa> OK
<alyssa> mostly i'm trying to understand why assign_dest (for example) takes an array of valuerefs instead of just one
<alyssa> but you're saying that's just TGSI legacy?
<airlied> what one value ref would it take?
<airlied> if dest has 4 components
<airlied> you can't do vectors of arrays of values in llvm IR
<alyssa> why would you ever have that, though?
<airlied> because we haven't scalarised 4 component stores
<alyssa> ooh
<airlied> though maybe in practice we have
<alyssa> like, store_ssbo?
<airlied> I think the main uses caess are the vec4 type constructors
<airlied> nir_vec4 etc
<alyssa> right..
<airlied> where you have one ssa value that is a vector of scalars but the scalars are 8-wide arrays
<alyssa> maybe I'm objecting to the "Loop for R,G,B,A channels" in the SoA case in visit_alu
ngcortes has quit [Ping timeout: 480 seconds]
<alyssa> not really interested in reworking this. just trying to figure out what to do for my NIR rework
<alyssa> and today is llvmpipe
<alyssa> day
fab has joined #dri-devel
tobiasjakobi has joined #dri-devel
benjaminl has quit [Ping timeout: 480 seconds]
<airlied> yeah so we do all the operations once on each component of the vector, then collect the results, then store them back as an array
tobiasjakobi has quit []
<airlied> I just didn't see the value for register stores of sticking them into an LLVM array
<airlied> just to pull them back out again
<airlied> since register stores actually go to memory, as opposed to just hide inside the ssa value hash table
<alyssa> why are there multiple components on the vector?
<alyssa> aren't we calling lower_alu_to_scalar in the SoA case?
<alyssa> I guess we aren't
<alyssa> we should be, I guess
<airlied> lavapipe does, not sure llvmpipe does
<airlied> probably a cleanup possible there
<alyssa> doesn't look like it does
<alyssa> yeah.. not today's cleanup though
<alyssa> currently defeaturing nir_register from llvmpipe
<airlied> there's probably quite a lot of llvm side stuff that could be moved to NIR side
<alyssa> Yeah
<airlied> it's mostly a legacy of TGSI and whatever state nir was in when I wrote it
<alyssa> piles of the graphics pipeline emulation code could be common NIR passes too I think
<alyssa> llvmpipe using nir_lower_blend anyone? ;-D
<airlied> oh that stuff is so finely hand written
<alyssa> D=
<airlied> I fear to tread in the blending pipeline, so many hand coded swizzle calls that I don't really understand
<gfxstrand> That sounds like a good argument for NIRifying
<alyssa> :crab_fire:
<airlied> it would be, but I doubt it would get as fast
<airlied> since it's mostly hand writing LLVM IR to optimise thing
<airlied> not sure translating NIR would achieve the same level, since NIR doesn't have a view into the LLVM 4-8 wide fun
<airlied> alyssa: I think the other reason we don't scalarise in NIR is for the soa/aos decision point there might not be a simple point to do it
<alyssa> hum
zf has quit [Quit: https://quassel-irc.org - Chat comfortably. Anywhere.]
zf has joined #dri-devel
zf has quit []
<mareko> alyssa: the CDNA thing is going to be answered in due time
<airlied> mareko: do you know if anyone runs a cdna card in a workstation? :-)
<mareko> airlied: I don't know much about where CDNA is used
<airlied> seems to be server gpus, but who wants a rack in their home :-P
<alyssa> mareko: mysterious ^_^
<mareko> other than what's publicly knows, such as El Capitan
<mareko> *known
<HdkR> airlied: I have a rack in my home :P
<HdkR> Might get a second one if I feel like experimenting a bit more
<airlied> HdkR: do you have soundproofing :-)
<airlied> the only locations I could put a rack would be near me or outside in the sun
<mareko> and cooling
<HdkR> Nah, I'm only rocking 4U chassis with slow spinning fans in it. Loudest thing is one of the 10gbit network switches
* airlied has to wear noise cancelling headphones to compile llvm or use the preprod navi33 card I have
<alyssa> Lool
<HdkR> Sounds about right for most rack-mount things :D
<karolherbst> airlied: that reminds me...
ngcortes has joined #dri-devel
<karolherbst> btw, how did you end up connecting that one to your system?
sima has quit [Ping timeout: 480 seconds]
<airlied> alyssa: seems to be about what I'd expect
<airlied> karolherbst: I ended up turning my machine on it's side, putting it on a cardboard box, and when I put that card in I stick another piece of cardboard box between it and the PSU to ensure it is supported
<alyssa> airlied: =D
<karolherbst> oof
<airlied> I really should get an PCIE extender so I can put it flat on something
<karolherbst> yeah.. I planend to use a PCIe extender as well...
<karolherbst> forgot about it
<alyssa> airlied: welp, 4 backends down, 11 to go.. ugh... https://gitlab.freedesktop.org/mesa/mesa/-/issues/9051
<airlied> alyssa: would be interested to see what CI says
<alyssa> me too
<jenatali> alyssa: Are there that many backends that consume registers?
<alyssa> jenatali: Sadly, yes
<DemiMarie> anholt: I take it you mean “kata containers”? Is that to prevent any more sandbox escapes?
<jenatali> Oof
<alyssa> though DXIL isn't one of them so you're off the hook I Guess
kts has quit [Remote host closed the connection]
<jenatali> Yep
<alyssa> I need to update the MR description
<alyssa> 'cause killing off abs/neg/sat modifiers is also in scope for this now :~)
zf has joined #dri-devel
<DemiMarie> Why is CDNA still considered a GPU? It can’t even do graphics, so I imagine it would belong under drivers/accel instead.
<alyssa> that's a lot less onerous though, since no mature backends use them
<alyssa> ntt, etnaviv, a2xx, lima, and r600
<alyssa> and I did ntt
<alyssa> IDK who's going to do the other 4
<alyssa> I typed up a lot of helpers to make it painless as possible to migrate, but even so
<alyssa> I'm not volunteering myself to work on those 4
fab has quit [Quit: fab]
benjaminl has joined #dri-devel
rasterman has joined #dri-devel
ngcortes has quit [Read error: Connection reset by peer]
rasterman has quit [Quit: Gettin' stinky!]
<alyssa> gfxstrand: ooh I hit the prog-to-nir thing in CI, fun
<alyssa> pushed to the MR the source/dest modifier stuff and the llvmpipe conversion at any rate
<alyssa> zink, you're up
mbrost has quit [Ping timeout: 480 seconds]
Duke`` has quit [Ping timeout: 480 seconds]
frankbinns1 has joined #dri-devel
Andrew-R has joined #dri-devel
HerrSpliet has joined #dri-devel
gcarlos57 has joined #dri-devel
jkhsjdhjs_ has joined #dri-devel
lcn_ has joined #dri-devel
enunes- has joined #dri-devel
phryk_ has joined #dri-devel
tonyk5 has joined #dri-devel
calebccff_ has joined #dri-devel
dwlsalmeida4 has joined #dri-devel
larunbe has joined #dri-devel
JoshuaAs- has joined #dri-devel
_jannau__ has joined #dri-devel
tales-aparecida8 has joined #dri-devel
<airlied> do I report spam or get unlimited vbucks, big choices
jeeeun8413519 has joined #dri-devel
macc24_ has joined #dri-devel
uajain_ has joined #dri-devel
milek7_ has joined #dri-devel
grillo_03 has joined #dri-devel
bnieuwenhuizen_ has joined #dri-devel
Plagman has joined #dri-devel
aleasto- has joined #dri-devel
Arsen_ has joined #dri-devel
gpiccoli_ has joined #dri-devel
V_ has joined #dri-devel
pH5_ has joined #dri-devel
mavchatz has joined #dri-devel
mlankhor1t has joined #dri-devel
xroumegue has quit [charon.oftc.net helix.oftc.net]
frankbinns2 has quit [charon.oftc.net helix.oftc.net]
RSpliet has quit [charon.oftc.net helix.oftc.net]
AndrewR has quit [charon.oftc.net helix.oftc.net]
alarumbe has quit [charon.oftc.net helix.oftc.net]
i-garrison has quit [charon.oftc.net helix.oftc.net]
mvchtz has quit [charon.oftc.net helix.oftc.net]
milek7 has quit [charon.oftc.net helix.oftc.net]
Hi-Angel has quit [charon.oftc.net helix.oftc.net]
bbrezillon has quit [charon.oftc.net helix.oftc.net]
jeeeun841351 has quit [charon.oftc.net helix.oftc.net]
mwk[m] has quit [charon.oftc.net helix.oftc.net]
bnieuwenhuizen has quit [charon.oftc.net helix.oftc.net]
mauld has quit [charon.oftc.net helix.oftc.net]
fdu has quit [charon.oftc.net helix.oftc.net]
kusma has quit [charon.oftc.net helix.oftc.net]
urja has quit [charon.oftc.net helix.oftc.net]
calebccff has quit [charon.oftc.net helix.oftc.net]
JosExpsito[m] has quit [charon.oftc.net helix.oftc.net]
enunes[m] has quit [charon.oftc.net helix.oftc.net]
nicofee[m] has quit [charon.oftc.net helix.oftc.net]
YaLTeR[m] has quit [charon.oftc.net helix.oftc.net]
ram15[m] has quit [charon.oftc.net helix.oftc.net]
halfline[m] has quit [charon.oftc.net helix.oftc.net]
APic has quit [charon.oftc.net helix.oftc.net]
LinuxHackerman has quit [charon.oftc.net helix.oftc.net]
gallo[m] has quit [charon.oftc.net helix.oftc.net]
bubblethink[m] has quit [charon.oftc.net helix.oftc.net]
danylo has quit [charon.oftc.net helix.oftc.net]
aradhya7[m] has quit [charon.oftc.net helix.oftc.net]
fkassabri[m] has quit [charon.oftc.net helix.oftc.net]
hch12907 has quit [charon.oftc.net helix.oftc.net]
Sumera[m] has quit [charon.oftc.net helix.oftc.net]
doras has quit [charon.oftc.net helix.oftc.net]
Eighth_Doctor has quit [charon.oftc.net helix.oftc.net]
T_UNIX has quit [charon.oftc.net helix.oftc.net]
go4godvin has quit [charon.oftc.net helix.oftc.net]
Mis012[m] has quit [charon.oftc.net helix.oftc.net]
Tooniis[m] has quit [charon.oftc.net helix.oftc.net]
talcohen[m] has quit [charon.oftc.net helix.oftc.net]
x512[m] has quit [charon.oftc.net helix.oftc.net]
tintou has quit [charon.oftc.net helix.oftc.net]
gdevi has quit [charon.oftc.net helix.oftc.net]
AlexisHernndezGuzmn[m] has quit [charon.oftc.net helix.oftc.net]
kunal10710[m] has quit [charon.oftc.net helix.oftc.net]
pinchart1 has joined #dri-devel
fdu_ has joined #dri-devel
vidal72[m] has quit [charon.oftc.net helix.oftc.net]
tuxayo has quit [charon.oftc.net helix.oftc.net]
heftig has quit [charon.oftc.net helix.oftc.net]
Soroush has quit [charon.oftc.net helix.oftc.net]
shoragan has quit [charon.oftc.net helix.oftc.net]
pH5 has quit [charon.oftc.net helix.oftc.net]
pinchartl has quit [charon.oftc.net helix.oftc.net]
siddh has quit [charon.oftc.net helix.oftc.net]
jkhsjdhjs has quit [charon.oftc.net helix.oftc.net]
tales-aparecida has quit [charon.oftc.net helix.oftc.net]
dwlsalmeida has quit [charon.oftc.net helix.oftc.net]
_jannau_ has quit [charon.oftc.net helix.oftc.net]
phryk has quit [charon.oftc.net helix.oftc.net]
gcarlos5 has quit [charon.oftc.net helix.oftc.net]
mlankhorst has quit [charon.oftc.net helix.oftc.net]
aleasto has quit [charon.oftc.net helix.oftc.net]
lcn has quit [charon.oftc.net helix.oftc.net]
tonyk has quit [charon.oftc.net helix.oftc.net]
macc24 has quit [charon.oftc.net helix.oftc.net]
Arsen has quit [charon.oftc.net helix.oftc.net]
grillo_0 has quit [charon.oftc.net helix.oftc.net]
uajain has quit [charon.oftc.net helix.oftc.net]
enunes has quit [charon.oftc.net helix.oftc.net]
V has quit [charon.oftc.net helix.oftc.net]
Plagman_ has quit [charon.oftc.net helix.oftc.net]
JoshuaAshton has quit [charon.oftc.net helix.oftc.net]
gpiccoli has quit [charon.oftc.net helix.oftc.net]
jeeeun8413519 is now known as jeeeun841351
lcn_ is now known as lcn
jkhsjdhjs_ is now known as jkhsjdhjs
lyudess has quit []
dwlsalmeida4 is now known as dwlsalmeida
grillo_03 is now known as grillo_0
Lyude has joined #dri-devel
mauld has joined #dri-devel
apinheiro has joined #dri-devel
APic has joined #dri-devel
urja has joined #dri-devel
xroumegue has joined #dri-devel
i-garrison has joined #dri-devel
bbrezillon has joined #dri-devel
<alyssa> the CI pipeline I mean
<alyssa> I am very confused
<jenatali> There was a failed job
<alyssa> and that failed the whole pipeline?
<alyssa> neat. that's new
<jenatali> Hm? Is it new?
rcf has quit [Ping timeout: 480 seconds]
<alyssa> maybe?
<alyssa> well, in that case I need help since IIRC iris doesn't build on arm
* alyssa tries anyway in case that was fixed
tintou has joined #dri-devel
go4godvin has joined #dri-devel
go4godvin is now known as Guest2915
pinchart1 is now known as pinchartl
<alyssa> oh, it does, cool
<alyssa> where's my drm-shim though
<alyssa> iris doesn't have drm-shim? :(
<alyssa> intel_stub_gpu. right
LinuxHackerman has joined #dri-devel
<alyssa> OK, reproduced
<alyssa> Ohhhh
<alyssa> Lol
<alyssa> OK
<alyssa> I see what happened
fkassabri[m] has joined #dri-devel
<alyssa> whoopsies
<alyssa> today's edition of "stupid spot the bug"
<alyssa> and fixed
<alyssa> well test still crashes for me because of arb_fragment_shader_interlock-image-load-store: ../src/intel/isl/isl_tiled_memcpy.c:609: choose_copy_function: Assertion `!"" "ISL_MEMCOPY_STREAMING_LOAD requires sse4.1"' failed.
<HdkR> A bit difficult to get SSE4.1 on your Macbook
<alyssa> Little bit yeah
<gfxstrand> hehe... Yeah....
<gfxstrand> I thought we had a non-SSE path
<alyssa> gfxstrand: you do, but iris was specifically asking for streaming
<gfxstrand> Ah, yes...
<gfxstrand> Because it can
<gfxstrand> Because it only runs BDW+ which is always paired with a GPU that supports SSE4.1
<gfxstrand> Unless that GPU is an Arc in which case it could be plugged into raspberry pi for all you know.
<alyssa> Yep
<alyssa> Well, not a raspberry pi I don't think
<alyssa> low to mid-tier arm doesn't work with dGPUs usually
<HdkR> Probably more a SolidRun Honeycomb or Ampere eMAG
<alyssa> yeah
<alyssa> server grade arm64 + dGPU
YaLTeR[m] has joined #dri-devel
<DemiMarie> Are there any mid-grade Arm64 chips?
<jenatali> Oof, that's a fun bug. Glad there was a test that caught it, though I'm surprised there was only one failure
<DemiMarie> mid-grade = desktop PC class
<gfxstrand> Apple
<gfxstrand> Otherwise, not that I'm aware of.
halfline[m] has joined #dri-devel
Piraty has quit [Remote host closed the connection]
<DemiMarie> Is that likely to ever change?
Piraty has joined #dri-devel
<jenatali> Some of QC's higher end chips are approaching that IMO
Hi-Angel has joined #dri-devel
<DemiMarie> gfxstrand: I’m a little bit salty about Apple having so many non-standard SMMUs. Means that Xen support for Apple Silicon is unlikely to ever happen.
hch12907 has joined #dri-devel
calebccff_ is now known as calebccff
<alyssa> gfxstrand: Hmm?
<alyssa> oh I see
<alyssa> ok, zink is converted too
<alyssa> I think that's enough backends for proving the design is sensible
Haaninjo has quit [Quit: Ex-Chat]
<alyssa> i'm off for the night then
T_UNIX has joined #dri-devel
<alyssa> pretty steady progress though
<alyssa> getting close to taking the Draft status off, so that's exciting
<alyssa> for me
<alyssa> not exciting if you were ignoring it and will soon have to convert your backends :~P
x512[m] has joined #dri-devel
apinheiro has quit [Quit: Leaving]
bgs has quit [Remote host closed the connection]
Sumera[m] has joined #dri-devel
rcf has joined #dri-devel
<Lynne> who works on vulkaninfo? khronos?
TMM has quit [Quit: https://quassel-irc.org - Chat comfortably. Anywhere.]
TMM has joined #dri-devel
smiles_ has joined #dri-devel
<gfxstrand> alyssa: Okay, I think I found at least some of the HSW regressions
<gfxstrand> lower_vec_to_movs is being a tiny bit more clever about placement of register stores.
<gfxstrand> But in a pretty niche edge-case
<bnieuwenhuizen_> Lynne: lunarg
<Lynne> do they have an issue tracker?
<Lynne> thanks, I thought about writing an equivalent to vainfo/vdpauinfo/nv-video-info, but thought it would be better off being a part of vulkaninfo
Kayden has quit [Quit: -> leaving office]
<gfxstrand> alyssa: Basically, you're missing try_coalesce
<gfxstrand> Or rather your coalesce_swizzle thing isn't quite as good for some reason.
<alyssa> gfxstrand: I'd believe it
JohnnyonF has quit [Ping timeout: 480 seconds]
<gfxstrand> alyssa: So the big difference as far as I can tell is that try_coalesce in lower_vec_to_movs puts the register write directly in the ALU op that generates the swizzle source. In a store_reg world, that would mean placing a store_reg immediately after.
<gfxstrand> alyssa: Whereas in lower_vec_to_regs, you insert the store_reg at the vec location and then eliminate the swizzling mov, leaving the store_reg as-is.
<gfxstrand> So the store_reg ends up living at the vec location.
<alyssa> => extra moves because that store isn't trivial
<alyssa> ?
<alyssa> s/isn't/may not be/
<gfxstrand> I'm not following
<alyssa> I may not be either
<alyssa> The reason the placement matters is presumably because putting the store_reg too late will cause nir_trivialize_registers to insert a move that won't be coalesced?
<gfxstrand> No
<gfxstrand> It's because, thanks to SSA, the coalescing that happens in try_coalesce works across blocks.
<gfxstrand> It doesn't matter if the fdp4 or whatever it is happens to be 17 blocks away, if the vec is the only user, we can re-swizzle it and write the register as part of the fdp4.
<alyssa> haswell supports control flow????????
<gfxstrand> Yes, sadly.
<gfxstrand> :P
<alyssa> we dont talk about broadwell, no no no
<gfxstrand> By contrast, when you emit the store_reg at the location of the vec and then try to coalesce later, the problem is much harder because you're moving a store_reg with insufficient information.
<gfxstrand> Well, you have enough information
<gfxstrand> It's possible
<gfxstrand> Each component is written exactly once
<gfxstrand> But it's a lot harder than when we're doing it in try_coalesce and the value we're dealing with is SSA.
* alyssa is trying to page in enough details of the passes for this to make sense
<alyssa> gfxstrand: I'm still not following why it matters where the store_reg instruction is placed
<alyssa> except I guess because trivialize_registers inserting extra moves because it doesn't see across bblock boundaries
<gfxstrand> It matters because back-end vec4 copy-prop and register coalesce suck
<alyssa> Oh, well, yes
<idr> Understatement of the year...
<alyssa> gfxstrand: I can try to reintroduce try_coalesce instead of the 2 pass thing
<alyssa> tomorrow, I mean. it's past working hours now I just saw an interesting problem
<gfxstrand> Yeah
<gfxstrand> That's fine
<alyssa> would ppreciate if you can send me a small affected shader that I can play with
<alyssa> but if not I can probably construct smoething
<alyssa> I don't really remember why I did the 2 pass thing
<gfxstrand> alyssa: It's sitting in your e-mail
<alyssa> thanks!
<alyssa> it appears I may have texted you the reason weeks ago but had disappearing messages on
<alyssa> couldn't have been that important (-:
paulk has joined #dri-devel
paulk-bis has quit [Read error: Connection reset by peer]
heat has quit [Remote host closed the connection]