sdutt has quit [Read error: Connection reset by peer]
Booti386_ has joined #dri-devel
Booti386_ has quit []
kem has quit [Ping timeout: 480 seconds]
fab has joined #dri-devel
kem has joined #dri-devel
khfeng has joined #dri-devel
mbrost has quit [Ping timeout: 480 seconds]
srslypascal is now known as Guest519
srslypascal has joined #dri-devel
MajorBiscuit has joined #dri-devel
lemonzest has joined #dri-devel
thellstrom has joined #dri-devel
Guest519 has quit [Ping timeout: 480 seconds]
fab has quit [Ping timeout: 480 seconds]
khfeng has quit [Remote host closed the connection]
khfeng has joined #dri-devel
danvet has joined #dri-devel
Duke`` has joined #dri-devel
khfeng has quit [Ping timeout: 480 seconds]
rasterman has joined #dri-devel
Duke`` has quit [Ping timeout: 480 seconds]
i-garrison has quit []
jkrzyszt has joined #dri-devel
i-garrison has joined #dri-devel
Duke`` has joined #dri-devel
pcercuei has joined #dri-devel
thellstrom has quit [Ping timeout: 480 seconds]
pjakobsson has quit [Remote host closed the connection]
nchery has joined #dri-devel
nchery is now known as Guest521
nchery has joined #dri-devel
lynxeye has joined #dri-devel
Guest521 has quit [Ping timeout: 480 seconds]
MrCooper has quit [Remote host closed the connection]
thellstrom has joined #dri-devel
MrCooper has joined #dri-devel
thellstrom has quit [Ping timeout: 480 seconds]
lemonzest has quit [Ping timeout: 480 seconds]
Major_Biscuit has joined #dri-devel
Daanct12 has quit [Remote host closed the connection]
MajorBiscuit has quit [Ping timeout: 480 seconds]
JohnnyonF has joined #dri-devel
luc4 has joined #dri-devel
MajorBiscuit has joined #dri-devel
Major_Biscuit has quit [Ping timeout: 480 seconds]
JohnnyonFlame has quit [Ping timeout: 480 seconds]
kts_ has joined #dri-devel
zf` has quit [Read error: Connection reset by peer]
zf` has joined #dri-devel
tarceri has quit [Remote host closed the connection]
tarceri has joined #dri-devel
thx has joined #dri-devel
thx has quit []
JohnnyonFlame has joined #dri-devel
JohnnyonF has quit [Ping timeout: 480 seconds]
rkanwal has joined #dri-devel
gawin has joined #dri-devel
Haaninjo has joined #dri-devel
JohnnyonF has joined #dri-devel
JohnnyonFlame has quit [Ping timeout: 480 seconds]
<gawin>
Kayden: I remember that once you've edited my commit in MR (to add rb), how did you do that? does gitlab create intermediate branches?
<emersion>
you can just clone the branch locally, then edit and push
<emersion>
if the MR author has checked the right box
<emersion>
there's a button somewhere to display instructions to clone locally
<emersion>
s/clone/checkout/
<gawin>
been wondering how it's handled on privileges level (I usually cannot edit your forks)
warpme___ has joined #dri-devel
<emersion>
there's an "allow to edit source branch" checkbox when submitting a MR
Company has quit [Quit: Leaving]
kts_ has quit [Ping timeout: 480 seconds]
<daniels>
karolherbst: yeah, looks like it's missing a dependency on the container job
JohnnyonFlame has joined #dri-devel
lina_ has joined #dri-devel
lina has quit [Ping timeout: 480 seconds]
JohnnyonF has quit [Ping timeout: 480 seconds]
lina has joined #dri-devel
gawin has quit [Ping timeout: 480 seconds]
YuGiOhJCJ has quit [Quit: YuGiOhJCJ]
lina_ has quit [Ping timeout: 480 seconds]
kts_ has joined #dri-devel
gawin has joined #dri-devel
poyo has joined #dri-devel
<FLHerne>
BAe 146 airbrakes are pretty radical for an airliner
<FLHerne>
er, wrong channel
<Rayyan>
lol
<HdkR>
You right though
poyo has quit [Remote host closed the connection]
heat_ has joined #dri-devel
pcercuei has quit [Quit: bbl]
Duke`` has quit [Ping timeout: 480 seconds]
gawin has quit [Ping timeout: 480 seconds]
Net147 has quit [Quit: Quit]
Net147 has joined #dri-devel
devilhorns has joined #dri-devel
Net147 has quit [Quit: Quit]
<karolherbst>
daniels: yeah.. I figured that out as well, but it's there in the .extends chain... oh well
Net147 has joined #dri-devel
rkanwal has quit [Ping timeout: 480 seconds]
Net147 has quit [Quit: Quit]
Net147 has joined #dri-devel
rkanwal has joined #dri-devel
Net147 has quit []
Net147 has joined #dri-devel
jewins has joined #dri-devel
Net147 has quit []
Net147 has joined #dri-devel
devilhorns has quit []
Haaninjo has quit [Quit: Ex-Chat]
pjakobsson has joined #dri-devel
alyssa has joined #dri-devel
<alyssa>
airlied: everything about !18136 makes me suspicious
off^ has quit [Remote host closed the connection]
sdutt has joined #dri-devel
kts_ has quit [Ping timeout: 480 seconds]
kts has joined #dri-devel
sergi8 has quit []
stuart has joined #dri-devel
stuart has quit []
stuart has joined #dri-devel
fxkamd has joined #dri-devel
LexSfX has joined #dri-devel
Net147_ has joined #dri-devel
Net147_ has quit []
bbrezill1 has quit []
Net147_ has joined #dri-devel
Net147 has quit [Read error: Connection reset by peer]
bbrezillon has joined #dri-devel
Net147_ has quit []
Net147 has joined #dri-devel
<JPEW>
Ok, I figured out more on my virtio gpu problem: For some reason the virtio kernel driver isn't allowing mesa to allocate dumb buffers from /dev/dri/renderD128 (it returns EACCES). Is that normal?
<emersion>
yes
<emersion>
render nodes can't do dumb buffers
<emersion>
dumb buffers are for KMS exclusively
eukara has quit []
eukara has joined #dri-devel
<JPEW>
Ah, so mesa is probably falling into trying to allocate a dumb buffer because it can't allocate a non-dumb one from virtio?
<JPEW>
(Even though this is impossible on a render node)
<Frogging101>
hakzsam: What do you mean by RADV_CMD_FLAG_INV_CACHE?
<Frogging101>
I see _ICACHE, _SCACHE, or _VCACHE
<hakzsam>
oh sorry, missed one letter, it's VCACHE
<Frogging101>
What's the WaW hazard here, by the way?
<hakzsam>
I think if we don't flush these caches, the hw might write values from the previous dispatch
<hakzsam>
in practice I think it won't happen because the copies will use CP DMA because they are very small, but it looks safer to flush
<Frogging101>
Okay
ManMower has quit []
Lucretia has quit [Read error: No route to host]
Surkow|laptop has quit [Remote host closed the connection]
Surkow|laptop has joined #dri-devel
Lucretia has joined #dri-devel
michael5050[m] has joined #dri-devel
gouchi has joined #dri-devel
fxkamd has quit []
Net147 has quit [Quit: Quit]
Net147 has joined #dri-devel
iive has joined #dri-devel
pjakobsson has quit [Remote host closed the connection]
shankaru1 has quit [Read error: Connection reset by peer]
shankaru has joined #dri-devel
Duke`` has joined #dri-devel
<dj-death>
Venemo: dumb question on !18143, why can't we just assume a default value when we see a c = phi(some_undef_ssa, some_const_ssa) ?
<Venemo>
dj-death: what do you mean by assume a default value?
lynxeye has quit [Quit: Leaving.]
jkrzyszt has quit [Ping timeout: 480 seconds]
MajorBiscuit has quit [Ping timeout: 480 seconds]
mbrost has joined #dri-devel
luc4 has quit [Ping timeout: 480 seconds]
<dj-death>
Venemo: essentially replace an undef by something that matches another branch
<Venemo>
dj-death: for example, consider this pattern: "if (a) { b = ... } else {} c = phi(b, 0)" to make this work, ACO inserts an instruction in the else block that writes 0. this means that even though the else was empty, it can't be removed. to solve that, the new code transforms the phi to: "c' = phi(b, undef); c = iand(a, c')". thanks to the undef, now ACO doesn't have to add any code to the else block and the branch will be deleted.
<Venemo>
I suppose this doesn't help backends that handle phis differently
<alyssa>
Venemo: hm wait why iand
<alyssa>
why not transform the phi to
<alyssa>
"c' = phi(b, undef); c = bcsel(a, c', 0)"
<alyssa>
you still get to delete the else block and coalesce the phi
<Venemo>
in this case the bcsel would be more expensive than the iand
<alyssa>
I guess the only difference is whether iand or bcsel is more efficient for booleans on your hw
<alyssa>
right, ok
<alyssa>
other way around on Mali
<alyssa>
(Maybe Mali needs iand of boolean -> bcsel rules, hum)
<Venemo>
if that helps you, I could change it to bcsel and optimize that to iand in the backend
<alyssa>
I mean I don't handle undefs in the backend yet
<alyssa>
I also have a lot of problems and this isn't one of them :p
<Venemo>
for us, being able to delete the branch means we can also get rid of the instructions which manage the exec mask in that branch. effectively this means we can remove more than 1 instruction when we have this case
<alyssa>
Sure
<alyssa>
It helps every backend in theory
<alyssa>
just requires smart undef handling and good idel in practice
<alyssa>
isel
<alyssa>
though maybe we should enable it as everyone and use the shaderdb as a carrot/stick to get backends to fix their RA :-p
<Venemo>
we could of course handle this special case in the backend ourselves, but that's very tricky. or we could enable this part of the opt only in RADV
<alyssa>
NIR is definitely the right place for it
<Venemo>
basically I'm solving a defect in our phi handling by hacking NIR
<alyssa>
How is it a hack?
<Venemo>
well, I'm just sayin it feels a bit dirty that I solve a backend specific problem in NIR
* alyssa
is curious how it affects backends that use nir_from_ssa + proper ssa_undef handling
<alyssa>
intel, for ex
<Venemo>
I guess that's a question for dj-death
<dj-death>
I'm not knowledgeable enough on this part
<Venemo>
can you run it through a shader db and see if it helps intel or not?
<Ristovski>
zmike: Are you going to allocate all mold linker time savings to blog content?
<Ristovski>
>finally, daily articles
<airlied>
alyssa: remind me next week, I don't want to page in u_transfer_helper on the weekend :-P
<zmike>
no
<alyssa>
airlied: this is unrelated to u_transfer_helper :)
<airlied>
alyssa: that was just a reply to your earlier comment :-P
<Ristovski>
:(
<alyssa>
aha
<alyssa>
airlied: No, the current problem is just that Panfrost really wants to know at shader compile time what type shader outputs have
<alyssa>
GLSL spec requires you to match types with fb formats and GLSL->NIR preserves that
<alyssa>
TGSI is typeless and TGSI->NIR just bullshits everything as float
<alyssa>
which is causing CTS fails for me on valhall
* karolherbst
wondering how nvc0 dealt with this with pure TGSI
<alyssa>
karolherbst: It's only a problem if your BLEND instruction depends on the src type (int/uint/float) but *not* the framebuffer format (then you just key the whole thing)
<alyssa>
of the 4 archs I work on, only 1 is like that (valhall)
<alyssa>
the problem with this sequence is that a perfectly valid reading is:
<alyssa>
sample the int values, reinterpret them as float32, and then convert the float values back to integers for the framebuffer format
<karolherbst>
store_output is a mess :(
<karolherbst>
alyssa: what's the nir_variable like btw?
<alyssa>
float32, because ttn makes up the type
<alyssa>
because the TGSI output is typeless
<karolherbst>
mhhh
<alyssa>
this is despite u_simple_shaders having the TGSI type right there and throwing it away
gouchi has quit [Quit: Quitte]
<karolherbst>
luckily for us it doesn't matter...
<karolherbst>
alyssa: why not just treat is as raw data? or are there cases where you actually have to convert?
<alyssa>
karolherbst: because the hw need to actually convert into the fb format
<karolherbst>
or do you have to encode the type or something?
<alyssa>
the float/uint/int is encoded in the blend so the hw conversion works
<karolherbst>
mhhh "annoying"
<alyssa>
BLEND.f32(0x3f800000) with R16_FLOAT framebuffer will write 0x3c00
<alyssa>
BLEND.u32(0x3f800000) with R16_FLOAT framebuffer will write 0x7c00
<karolherbst>
alyssa: can the right type derived from the TGSI or external information? Than I suggest ttn simply needs some adjustments to make all store_outputs to be correctly typed
<alyssa>
not in general
<alyssa>
because you could do uintBitsToFloat or intBitsToFloat
<alyssa>
which I assume are both implicit in TGSI because, again, typeless
<airlied>
yeah you'd need to add something to the output semantic
<alyssa>
airlied: yep. so now you get to my "augment TGSI, rewrite core code to be NIR, or give up and add a shader key" dilemma
<karolherbst>
alyssa: there are no implicit conversions afaik
<alyssa>
those aren't conversions, they're reinterpretation
<karolherbst>
well.. you don't need those either
* airlied
would have thought shader key was the "proper" way to do it
<karolherbst>
the instruction decides on how to interpret bits
<airlied>
but I understand wanting to avoid it
<alyssa>
airlied: both OpenGL and Vulkan specs are written to ensure you don't need a shader key for this
<alyssa>
it seems really iffy to add one just because TGSI is dumb
<karolherbst>
alyssa: I suspect no TGSI driver ever needed it
<karolherbst>
so OUT doesn't have a type
<airlied>
yeah no TGSI driver ever cared
<airlied>
like SVIEW didn't grow a type for agse
<karolherbst>
I suspect we'd have to add support for that to TGSI or safe the information until later for ttn
<karolherbst>
and just use that stored type when emiting store_output
<alyssa>
although.. Valhall does have a BLEND.auto32 that uses whatever type matches the framebuffer
<alyssa>
which I guess is always safe, even for broken TGSI shaders ...
<karolherbst>
alyssa: I assume we lose that information when going from GLSL to TGSI, no?
<karolherbst>
ehhh.. wait
<karolherbst>
those are builtin shaders
kts has quit [Ping timeout: 480 seconds]
<karolherbst>
alyssa: which is the broken one for you?
aswar002 has joined #dri-devel
ngcortes has joined #dri-devel
<alyssa>
karolherbst: util_make_fragment_tex_shader with integers
<karolherbst>
what's dtype when it's called?
<karolherbst>
is it the correct type or something random?
<alyssa>
(U)INT i assume
<alyssa>
but dtype isn't plumb into the actual TGSI
<karolherbst>
are you hitting it because of u_blitter?
<alyssa>
yes
<karolherbst>
mhhh
<karolherbst>
annoying
Akari has quit [Remote host closed the connection]
<alyssa>
truly
Akari has joined #dri-devel
<alyssa>
let's see if te BLEND.auto32 hack works
<karolherbst>
it better be, otherwise fixing it feels like to be pain
<alyssa>
100%
* alyssa
kind of wishes we had a nir->info.buggy_tgsi propert
<karolherbst>
:D
<karolherbst>
create one
<alyssa>
(AUTO works)
<karolherbst>
yay
<karolherbst>
my other suggestion would be to track down the source of the store_output and find the first typed instruction
<alyssa>
that doesn't work
<karolherbst>
:/
<karolherbst>
we should ditch TGSI for good
<karolherbst>
:D
<alyssa>
oh, nice, we have that flag...
<alyssa>
info->fs.untyped_color_outputs
<karolherbst>
:D
<alyssa>
Meh, my name was more creative :-p
<karolherbst>
but does that actually help you or will you just always use AUTO?
<alyssa>
It does help!
<alyssa>
It lets me use auto for broken TGSI shaders and proper types otherwise
<karolherbst>
wondering if using proper types has any advantages.. but I guess it has otherwise it wouldn't be there
<alyssa>
Unfortunately backfired because now the CVT unit is overloaded, ah well...
<alyssa>
maybe Valhall needs a scheduler to balance the pipes after all. grumble.
<Venemo>
alyssa: overloaded? whoah.
<alyssa>
Venemo: CVT handles all the random instructions
<Venemo>
aha
<alyssa>
Everything but FMA, FADD, bitwise, and special functions.
<alyssa>
In practice things seem to be FMA pipe bound, of course.
<alyssa>
(Of the ALU bound set. In actual practice things are memory bandwidth bound :-p)
<alyssa>
Venemo: Re your phi-undef MR, I do wonder if the extra reg pressure from keeping the condition live is a problem
nchery has joined #dri-devel
<Venemo>
not a problem for us according to the stats, but who knows.
<alyssa>
nod
<alyssa>
Intriguing that patch is actually a win on Bifrost.
<alyssa>
I guess because the clause scheduler can revert the opt when it hurts.
<Venemo>
I also saw some strange behavior on intel, there may be a bug
<Venemo>
same for aco actually
<alyssa>
(I mean just the linked bifrost patch, not with your code.)
<Venemo>
right, sorry
<Venemo>
in one of the shaders there is a big chunk of CF deleted and I'm not quite sure why
<alyssa>
oops
thellstrom has quit [Read error: Connection reset by peer]
thellstrom has joined #dri-devel
<JPEW>
Is there anyway to test my application that uses DMABUfs for offscreen rendering (/dev/dri/renderD128, think weston-simple-dmabuf-egl) on QEMU with software rendering? Nothing seems to be working out for me