ChanServ changed the topic of #dri-devel to: <ajax> nothing involved with X should ever be unable to find a bar
UnOriginalOne has joined #dri-devel
columbarius has joined #dri-devel
co1umbarius has quit [Ping timeout: 480 seconds]
AlexisHernndezGuzmn[m] has joined #dri-devel
kunal10710[m] has joined #dri-devel
knr has joined #dri-devel
tleydxdy has joined #dri-devel
Kayden has quit [Quit: home]
<zmike>
karolherbst: vvl already handles validation for spirv and spirv-val does the same
<karolherbst>
zmike: I meant like checking if the SPIR-V declares any extensions a driver doesn't support
<zmike>
yep that's part of it
lemonzest has quit [Quit: WeeChat 3.6]
<karolherbst>
how would that work through spirv-val then?
<karolherbst>
I know it can print if one forgets to specify an extension
<zmike>
ah spirv-val just does the base validation
<zmike>
vvl handles device caps
<karolherbst>
right.. but I can't use vvl from inside CL, so that would be an issue. Guess I'll just trust on spirv_to_nir to fail
<zmike>
why can't you
<karolherbst>
how could I
<zmike>
zink ?
<karolherbst>
gallium is a dead end
<zmike>
🤔
<karolherbst>
cl did become command buffer extensions e.g.
<karolherbst>
and mapping that to gallium or reworking gallium to support that would be pure pain
<zmike>
I'm not sure what you mean
<karolherbst>
and it sounds like implementors want to focus more on that
<zmike>
like the GL cmdbuf ext?
<karolherbst>
no, like vulkan command buffers
<zmike>
yea there's that nv gl ext that's kinda similar
<karolherbst>
funky
<karolherbst>
but still sounds like pain to do in gallium
<zmike>
why?
<karolherbst>
I mean.. you could record it and call gallium apis
<karolherbst>
but that defeats the purpose
<zmike>
I'd expect you could do it with gallium by just adding begincmdbuf / endcmdbuf / exec interfaces
<karolherbst>
uhhh
<karolherbst>
yeah well...
<zmike>
then the driver would create and manage an IB with the commands that could be reused
<karolherbst>
yeah.. that basically means to rewrite most/all drivers
<zmike>
not sure about that one
<zmike>
would be pretty trivial in zink at least
<karolherbst>
yeah.. in zink
<zmike>
isn't that where you wanted validation anyway?
<karolherbst>
could be a zink only interface, but then again
<karolherbst>
not really
<zmike>
I mean in the cmdbufs
<alyssa>
openzl
<alyssa>
zusticl?
<karolherbst>
I'm also not sure how much value zink adds in terms of CL
<zmike>
stop couple naming my driver
<karolherbst>
ntv is super usefull
<karolherbst>
but besides that? mhh not sure
<karolherbst>
what would you say how much of zink deals with messy vk compute stuff?
<karolherbst>
5%?
<zmike>
I don't know what you're asking
<alyssa>
writing a compute-only gallium driver for rusticl (if you already have a vulkan driver in-tree) doesn't seem like a big deal anyhow
<karolherbst>
yeah...
<alyssa>
but i'll zip my mouth with my gallium propaganda
<karolherbst>
my point is rather, the compute side of things is so trivial, that targeting vulkan directly or using zink wouldn't do much of a difference
<karolherbst>
I'm just wondeirng how one could deal with extensions like command buffers through gallium
<karolherbst>
for now it doesn't matter anyway
<karolherbst>
but yeah.. no idea
<karolherbst>
maybe I prototype it when I find some time
<karolherbst>
anyway
yuq825 has joined #dri-devel
ngcortes has quit [Read error: Connection reset by peer]
lemonzest has joined #dri-devel
jkrzyszt has quit [Ping timeout: 480 seconds]
Kayden has joined #dri-devel
UnOriginalOne has quit [Ping timeout: 480 seconds]
nyorain[m] has joined #dri-devel
ohadsharabi[m] has joined #dri-devel
Leopold_ has quit [Remote host closed the connection]
kugel has quit [Read error: Connection reset by peer]
kugel has joined #dri-devel
ids1024[m] has joined #dri-devel
heat has quit [Ping timeout: 480 seconds]
flto has quit [Ping timeout: 480 seconds]
zamundaaa[m] has joined #dri-devel
UnOriginalOne has quit [Ping timeout: 480 seconds]
reactormonk[m] has joined #dri-devel
marmarek[m] has joined #dri-devel
dcz_ has joined #dri-devel
crabbedhaloablut has quit [Read error: No route to host]
bmodem1 has joined #dri-devel
Zopolis4 has joined #dri-devel
crabbedhaloablut has joined #dri-devel
bmodem has quit [Ping timeout: 480 seconds]
jenatali has joined #dri-devel
x512[m] has joined #dri-devel
itoral has joined #dri-devel
K0bin[m] has joined #dri-devel
Tooniis[m] has joined #dri-devel
talcohen[m] has joined #dri-devel
YuGiOhJCJ has joined #dri-devel
fab has joined #dri-devel
eukara has quit [Ping timeout: 480 seconds]
<airlied>
26.4g 13.9g virt/res for one mesh test, might need to fix that
rasterman has joined #dri-devel
tomba has joined #dri-devel
undvasistas[m] has joined #dri-devel
bmodem1 has quit [Ping timeout: 480 seconds]
mvlad has joined #dri-devel
bmodem has joined #dri-devel
fab has quit [Quit: fab]
sima has joined #dri-devel
aravind has joined #dri-devel
frieder has joined #dri-devel
tursulin has joined #dri-devel
sghuge has quit [Remote host closed the connection]
sghuge has joined #dri-devel
UnOriginalOne has joined #dri-devel
UnOriginalOne has quit [Ping timeout: 480 seconds]
<pq>
zamundaaa[m], sure, but if all of that 400 nits available through simple brightness adjustment a.k.a backlight, or is there a hidden switch somewhere to go to "HDR mode"?
<pq>
zamundaaa[m], btw. which HDR modes does EDID tell you to be available?
<pq>
zamundaaa[m], vsyrjala, what does the Colorspace property set to BT2020 actually do in the driver and hardware, given the panel itself can only take panel-native pixel values I presume?
<pq>
If the panel takes any data given to it in its native pixel values, then sending it BT2020 encoded content whose actual used color gamut is smaller would indeed result in a desaturated image.
<pq>
or does an eDP panel actually have similar pixel processors like standard HDMI/DP interface monitors do?
<pq>
zamundaaa[m], seeing what edid-decode says about the EDID would be interesting.
<jani>
pq: I didn't read the backlog, but some panels actually do have a hidden switch. e.g. you have to write the source OUI to specific DPCD registers, and the panel behaves differently. (isn't that lovely?)
<pq>
jani, yay.
<pq>
jani, is that hooked up to KMS UAPI somehow?
<pq>
e.g. would setting HDR_OUTPUT_METADATA property make the driver automatically program that?
<jani>
pq: it's done unconditionally by e.g. i915
UnOriginalOne has joined #dri-devel
<jani>
intel_edp_init_source_oui() in drivers/gpu/drm/i915/display/intel_dp.c
<pq>
oh, so what behavior do we unconditionally get?
<jani>
HDR backlight, for example
<pq>
what about the color encoding of pixel values?
<pq>
does it make pixel values to be expected in panel-native color gamut, or?
heftig has joined #dri-devel
<jani>
I have no idea
<pq>
heh, so that's a question we need an answer for, and the effect of Colorspace property on eDP as well :-)
<pq>
Ideally, if a driver exposes Colorspace and HDR_OUTPUT_METADATA properties for an eDP panel, and if that eDP panel does not handle those *at all*, then the driver would need to do something about it. Or expose something completely different so that userspace knows it needs to handle all that itself.
<pq>
hwentlan_, ^
jkrzyszt has joined #dri-devel
pcercuei has joined #dri-devel
fab has joined #dri-devel
lynxeye has joined #dri-devel
swalker__ has joined #dri-devel
swalker_ has joined #dri-devel
swalker_ is now known as Guest321
swalker__ has quit [Ping timeout: 480 seconds]
dcz_ has quit [Ping timeout: 480 seconds]
bmodem has quit [Ping timeout: 480 seconds]
rcf has quit [Ping timeout: 480 seconds]
<jani>
pq: if I got a euro for every display that has bogus info in EDID or DPCD, I'd be a wealthy man :p
rasterman has quit [Remote host closed the connection]
rasterman has joined #dri-devel
rasterman has quit [Remote host closed the connection]
rasterman has joined #dri-devel
<pq>
jani, I did not yet even consider EDID to be incorrect, that just another thing on top of all this. :-)
jasuarez has joined #dri-devel
<pq>
well, the EDID in that issue seems to be WCG SDR by the impression of the numbers, even though it claims ST2084 TF too.
<pq>
the primaries and white point are off enough from any standard that they might even be true, who knows
Lucretia has quit []
general_j[m] has joined #dri-devel
Peuc has quit [Ping timeout: 480 seconds]
<pq>
oops, I read the wrong column. The luminance values are HDR indeed in that EDID.
sythemeta847[m] has joined #dri-devel
Peuc has joined #dri-devel
<zamundaaa[m]>
It's not my laptop but I can ask. IIRC Nate doesn't have Windows on it though
Company has joined #dri-devel
The_Company has joined #dri-devel
mvchtz has quit [Quit: WeeChat 3.5]
mvchtz has joined #dri-devel
<pq>
zamundaaa[m], why Windows?
bmodem has joined #dri-devel
<pq>
The thing with Colorspace and HDR_OUTPUT_METADATA is that they are only relayed to the "monitor" and then it's the monitor that should make use of them. I wonder why would an internal panel have the necessary circuitry to make use of them.
<pq>
In the end, HDR is "just" about preparing the content for the display differently, bumping the maximum possible luminance way, up and using greater pixel bit depth to adequately cover the new dynamic range. One can compromise on everything except "preparing content differently" while still getting a HDR'ish look but just lower quality.
<pq>
zamundaaa[m], is that gitlab issue linked earlier exactly the case you are looking at?
<zamundaaa[m]>
No, but it is pretty similar
Zopolis4 has quit [Quit: Connection closed for inactivity]
bmodem has joined #dri-devel
sgruszka has joined #dri-devel
Leopold_ has quit [Remote host closed the connection]
milek7_ has quit [Ping timeout: 480 seconds]
The_Company has quit []
Leopold_ has joined #dri-devel
m00nlit[m] has joined #dri-devel
<pq>
zamundaaa[m], that's a quite basic looking HDR EDID. I'm getting the feeling that the primaries are somewhat meaningful, the luminances are filled in in a very simple manner, and the TFs might be a copy&paste...
vidal72[m] has joined #dri-devel
<pq>
zamundaaa[m], have you tried setting HDR_OUTPUT_METADATA max luminance to 400 cd/m²? I wouldn't expect it to make a difference for an internal panel, but who knows.
<vsyrjala>
did we try i915.enable_psr=0 already?
<zamundaaa[m]>
vsyrjala: no, I didn't get a response yet
<zamundaaa[m]>
pq: there is no HDR_OUTPUT_METADATA, the APU doesn't support it
<pq>
oh right, then you have no switch to turn HDR on, except ramping backlight up to max.
milek7 has joined #dri-devel
<zamundaaa[m]>
vsyrjala: how is HDR metadata & Colorspace *supposed* to work with internal displays btw?
<pq>
which for an internal panel might as well be the right thing to do, dunno
<pq>
wonder how wide bits per pixel are actually flowing through the eDP...
<zamundaaa[m]>
Like, does the driver do automatic color conversions behind the users back, or is there an additional controller doing this, or is userspace expected to send the raw rgb values for the display, or...?
Leopold_ has quit [Remote host closed the connection]
<pq>
that question boils down to what internal panels actually do, do they use the infoframe data for anything
Leopold_ has joined #dri-devel
<pq>
from KMS UAPI perspective, there should not be a difference between external monitors and internal panels, but the panel hardware may be different and if so, I'd personally expect the driver to either compensate or not expose the properties.
Vin[m] has joined #dri-devel
<pq>
Unfortunately when no such properties exist, the expectation is a color encoding close to sRGB SDR. But it might as well be panel-native pixel encoding. A "monitor driver" file would probably contain the information for Windows, I guess. Or maybe Windows special-cases eDP + certain EDID values in order to produce panel-native pixels.
<pq>
I would expect to find a switch between "sRGB emulation" and "panel native" pixel encodings, which might be what jani talked about.
flto has joined #dri-devel
<zamundaaa[m]>
pq: same, but we don't have such a thing in KMS, right? When I set Colorspace to BT2020_RGB, something still needs to convert that to the panel native pixel encoding
<pq>
Yes, which is why I think the Colorspace property might not apply for internal panels if they don't have the processor for that.
<zamundaaa[m]>
swick: but the EDID does say that in this case
<pq>
this needs either specs or reverse-engineering what happens on the sink side of eDP, and once we know that, we can think how and if the KMS properties should be handled in a driver.
<pq>
if swick is talking, he's not coming through to irc
<pq>
zamundaaa[m], I think EDID is only trustworthy up to what bits of it is used by Windows.
<pq>
and if Windows special-cases eDP, or punts everything to a "panel driver", we'd have to do the same
MajorBiscuit has joined #dri-devel
YuGiOhJCJ has quit [Quit: YuGiOhJCJ]
go4godvin has joined #dri-devel
go4godvin is now known as Guest340
Guest340 is now known as go4godvin
itoral has quit [Quit: Leaving]
UnOriginalOne has quit [Ping timeout: 480 seconds]
juano has joined #dri-devel
juano has quit [autokilled: Possible spambot. Mail support@oftc.net if you think this is in error. (2023-05-16 12:48:07)]
swick[m] has joined #dri-devel
Mis012[m] has joined #dri-devel
eyearesee has joined #dri-devel
camus has quit [Ping timeout: 480 seconds]
cmichael has quit [Remote host closed the connection]
dsrt^ has quit [Remote host closed the connection]
fab has joined #dri-devel
viciouss[m] has joined #dri-devel
Mershl[m] has joined #dri-devel
djbw has joined #dri-devel
sgruszka has quit [Ping timeout: 480 seconds]
vliaskov has joined #dri-devel
smiles_1111 has quit [Ping timeout: 480 seconds]
cmichael has quit [Quit: Leaving]
aravind has quit [Ping timeout: 480 seconds]
Guest321 has quit [Remote host closed the connection]
frieder has quit [Remote host closed the connection]
gouchi has joined #dri-devel
MajorBiscuit has quit [Ping timeout: 480 seconds]
<zmike>
jenatali: fwiw you're not alone, I never know anything exists in nir until someone points it out
<Ristovski>
and then everyone else finds out from your blog :P
doras has joined #dri-devel
lynxeye has quit [Quit: Leaving.]
<alyssa>
zmike: just this week I discovered nir_intrinsic_copy_const_indices
<zmike>
literally what
<jenatali>
I still need to port to load_ubo_vec4 and lower_mem_bit_sizes
ella-0[m] has joined #dri-devel
thenemesis has joined #dri-devel
thenemesis has quit []
bmodem has quit [Ping timeout: 480 seconds]
Hazematman has joined #dri-devel
znullptr[m] has joined #dri-devel
pac85[m] has joined #dri-devel
Sumera[m] has joined #dri-devel
jkrzyszt has quit [Ping timeout: 480 seconds]
<alyssa>
zmike: same
junaid has joined #dri-devel
junaid_ has joined #dri-devel
mdroper has joined #dri-devel
<Kayden>
so I was working on some nir_opt_load_store_vectorize related improvements for load/store globals
<Kayden>
and I noticed that fossil-db was showing no improvements
<Kayden>
I discovered that in the one fossil I was looking at, it was enabling robustBufferAccess, which disabled vectorization for globals
<alyssa>
!
<Kayden>
it's a DX12 app from vkd3d-proton
<Kayden>
oddly... fossilize commit 945aacaa9b3d5cc1ac75b54d68c94c6520df9745 (Capture mesh shader feature PDF2s as well.) is what's causing it to suddenly enable robustBufferAccess
<Kayden>
it -sounds- like fossilize is intending to enable robustness if the captured pipeline requested it, but otherwise it's disabling it. and, for older fossils, it's filling in "please disable robustness". which sounds like a fine plan but I'm not sure if it's working right
<Kayden>
with that commit I get an opts.features != NULL and prior to that I get opts.features == NULL causing it to fill in default PDFs
<pendingchaos>
RADV used to add global to the robust_modes too, but I decided that it wasn't necessary
<pendingchaos>
since robust_modes is supposed to avoid address overflow within the load like "load32(-4); load32(0)" -> "load_2x32(-4)", but the original IR wouldn't have worked because address 0 is invalid for globals
<Kayden>
pendingchaos: interesting, I was thinking it was something to do with bounds checking of components
<pendingchaos>
it shouldn't if the vectorized load is aligned to the size of the entire load
<zmike>
ah ok
<zmike>
so like a uint load with offset aligned to uint would vectorize
<pendingchaos>
no, it's to avoid loads/stores crossing negative->positive/zero offsets
<Kayden>
hmm, yeah, that doesn't seem necessary then
<pendingchaos>
zmike: aligned to the size of the entire vectorized load
<pendingchaos>
so 2x32 requires 8 byte alignment and 4x32 requires 16 byte alignment
<zmike>
right
<pendingchaos>
I believe the vectorization is fine without robust buffer access because there's a line in the vulkan spec saying a load might be considered out of bounds if a load with a similar offset also is out of bounds
<pendingchaos>
so that load32(-4) can mess up a load32(0)
rasterman has joined #dri-devel
ngcortes has joined #dri-devel
martijnbraam has joined #dri-devel
alanc has quit [Remote host closed the connection]
alanc has joined #dri-devel
<alyssa>
phase 1 one of my plan to kill nir_register underway
<alyssa>
(-:
<alyssa>
TBD if I can finish this one off though. Optimistic but atomics was just a warmup
<airlied>
alyssa: whats wrong with nir register?
hch12907 has joined #dri-devel
enick_444 has joined #dri-devel
<alyssa>
airlied: Extremely invasive in the IR
<alyssa>
and doing nothing for drivers that ingest SSA other than bloat memory footprint and slow things down
<airlied>
what about drivers that ingest registers? :-)
<alyssa>
Connor, Faith, and I have been talking about replacing nir_reg_src/nir_reg_dest with special load/store_reg intrinsics for years now
<airlied>
ah makes sense
<alyssa>
This week's project is evaluating the feasibility of that
<alyssa>
I mean obviously it can be done
<alyssa>
the question is can it be done without regressing perf on the non-SSA drivers
<alyssa>
so I'm writing fresh Midgard compiler code for the first time in ... IDK how long, it's been a while
<alyssa>
my vec4 baby :~)
<jenatali>
Could they just be nir_variable with nir_var_register as the memory mode?
<jenatali>
Or is that still too much bloat?
<jenatali>
Eh I guess you'd lower_io and get load/store register intrinsics anyway, nvm
<alyssa>
jenatali: considered that but registers are sufficiently special that I don't want to do multiple cross-tree reworks at once
<alyssa>
so what I have WIP'd are a set of intrinsics that map 1:1 to nir_register/nir_reg_src/nir_reg_dest just in instruction form
<alyssa>
and a pass to translate from old to new
Leopold__ has joined #dri-devel
<alyssa>
next up is teaching midgard to ingest those intrinsics, and adding some more passes/helpers so we're not relying on midgard's backend copyprop
<alyssa>
(which is... not great, and probably better than some of the vec4 backends we have in tree relying on nir_register for perf)
Leopold_ has quit [Ping timeout: 480 seconds]
fkassabri[m] has joined #dri-devel
ofirbitt[m] has joined #dri-devel
q4a has joined #dri-devel
pp[m] has joined #dri-devel
<alyssa>
(The copyprop is the hard part of the problem here. Luckily I've got plans for that too.)
junaid has quit [Remote host closed the connection]
junaid_ has quit [Remote host closed the connection]
gouchi has quit [Remote host closed the connection]
rauji__ has quit []
dhirschfeld2[m] has joined #dri-devel
Nirvin[m] has joined #dri-devel
<karolherbst>
alyssa: what are the use cases for nir_register atm? phi resolving and what else?
<anholt_>
karolherbst: function local variables with array indexing not lowered to scratch
<karolherbst>
that's just for indirects if the driver supports it, right?
mvlad has quit [Remote host closed the connection]
<karolherbst>
could be made a drivers problem to convert scratch to.. indrect register acesses if they feel like it
<anholt_>
karolherbst: it is already the driver's problem.
<anholt_>
the goal is to reduce the impact on the rest of nir from the existence of regs, while not regressing codegen across drivers.
<karolherbst>
fair enough
jaganteki has quit [Remote host closed the connection]
<alyssa>
karolherbst: yep -- phi resolving, some indirect arrays, and also partial writes to vectors on vec4 backends
<karolherbst>
uhhh partial vector writes..
<alyssa>
That's why I'm doing bring up against my vec4 compiler :)
<alyssa>
I figure if I can implement something that's good enough for midgard, it'll be good enough for everyone
<karolherbst>
that's probably a fair assumption
<alyssa>
I'll write the patches for midgard and ntt regardless
<karolherbst>
I'm still playing with the idea of merging load_uniform with load_kernel_input by just forcing every driver to do byte addressing instead of silly 32bit or vec4 games
<alyssa>
unsure what my plan is for all the random backends
<karolherbst>
but not sure how many drivers will hate me for it
<alyssa>
TBD how invasive the change is
jaganteki has joined #dri-devel
<airlied>
karolherbst: not all hw can do byte addressing though
<karolherbst>
mhh...
<karolherbst>
annoying
<alyssa>
not all hw deserves opencl support :p
<airlied>
pretty sure a lot of older hw can only do vec4
<airlied>
yes totally dont expect CL
tursulin has quit [Ping timeout: 480 seconds]
<airlied>
just that fixing load uniform isnt that easy
<alyssa>
my point is, can't you just do load_ubo instead of load_kernel_input and not touch load_uniform?
<alyssa>
jenatali: I want to iterate the shader in source order. How do I do that?
<alyssa>
Bit of an X/Y problem
<alyssa>
Uh
<jenatali>
nir_foreach_block?
<alyssa>
That doesn't get me the if conditions
<jenatali>
Or do you need to iterate the CF nodes in source order?
sukrutb has joined #dri-devel
<alyssa>
I want to check for each use of a load_reg intrinsic that there is no intervening store_reg intrinsic
<alyssa>
(what would become write-after-read hazards if not dealt with)
<alyssa>
Conceptually there's a simple algorithm
<alyssa>
foreach block {
<jenatali>
Why do you need if sources?
<alyssa>
foreach instr in block {
<alyssa>
if instr == load_reg {
<alyssa>
valid_set |= instr
<alyssa>
} else if instr == store_reg {
<alyssa>
valid_set -= instr
<alyssa>
} else {
<alyssa>
foreach src in instr {
<alyssa>
if src is load_reg, assert(src in valid_set)
<alyssa>
..
<alyssa>
}
<alyssa>
Problem is that misses the if's
<alyssa>
since if-sources don't happen in a block in NIR
<jenatali>
I see
<alyssa>
and I need to be able to gaurantee there's no something dumb like
<alyssa>
x = load_reg r
<alyssa>
store_reg r, foo
<alyssa>
if x {
<alyssa>
..
<alyssa>
}
<alyssa>
(well, either guarantee it's not there, or insert a mov after the load_reg and read from the mov instead)
<jenatali>
alyssa: Look at the nir_foreach_block implementation, note it uses nir_block_cf_tree_next, use nir_cf_node_cf_tree_next to write an equivalent foreach loop, then check the node type and cast to block or check if source
<alyssa>
Will give that a try
<alyssa>
thanks :)
<alyssa>
(Note I am trying to do this locally, i.e. valid_set is per block only. I just.. want to think of if conditions as being read at the end of the preceding block)
<jenatali>
alyssa: You might want to just check the current block's next cf node then (if there is one) to see if it's an if
<jenatali>
alyssa: nir_block_get_following_if
<alyssa>
yeah, I was looking at that just now
<alyssa>
shouldn't be able to have more than one if, either, since there'd be an intervening then block.. I think
<jenatali>
Correct
<Kayden>
yeah, I think walking blocks and using nir_block_get_following_if is probably the easiest plan
<jenatali>
IIRC nir requires that after the if/else block there's also a block before any additional control flow
<Kayden>
the if condition is basically executed in that block anyway
jernej_ is now known as jernej
<alyssa>
+1
<alyssa>
thank you both :)
pyromancy has left #dri-devel [#dri-devel]
mbrost has joined #dri-devel
mbrost_ has joined #dri-devel
rasterman has quit [Quit: Gettin' stinky!]
<alyssa>
airlied: lavapipe getting working mesh shaders before anv? =P
mbrost has quit [Ping timeout: 480 seconds]
<airlied>
alyssa: depends on how fast I can clean up the code :-P
apinheiro has joined #dri-devel
<airlied>
current branch passes cts at least
Quinten[m] has joined #dri-devel
<jenatali>
Nice :)
<alyssa>
=D
<alyssa>
how bad is software-only mesh?
<alyssa>
relative to e.g. geom and tess?
<alyssa>
s/and/or/
vjaquez has quit [Remote host closed the connection]
vjaquez has joined #dri-devel
<jenatali>
When I did it in WARP it was... not great
<jenatali>
My problem was the ordering requirements. I might've just not been familiar enough with the internals but I couldn't figure out a good way to sort the geometry without just serializing things
mbrost_ has quit [Ping timeout: 480 seconds]
<alyssa>
uff
<airlied>
yeah I do lack for any overlap
<airlied>
but I think it's probably faster than vs/gs/tess in llvmpipe
<airlied>
because I can at least thread the task and mesh shader execution itself
fab has quit [Quit: fab]
<alyssa>
I'm dragging my feet on GS on asahi
<alyssa>
because, yeah
aradhya7[m] has joined #dri-devel
<airlied>
one good thing is there's no xfb
danylo has joined #dri-devel
<alyssa>
oh thank god
bubblethink[m] has joined #dri-devel
kunal_10185[m] has joined #dri-devel
shoffmeister[m] has joined #dri-devel
<alyssa>
well. GS, I have a plan but I hate it. TS, I have no plan other than *handwave* compile the warp/llvmpipe tessellator as a CL kernel
LaughingMan[m] has joined #dri-devel
<airlied>
just lower it all to task/mesh :-P
<airlied>
though I suppose you then lower task/mesh to cs anyways :-P
<alyssa>
Yep :P
<alyssa>
the really icky case is primitive restart + { XFB, GS, TS }
<alyssa>
in gl I just draw_vbo_without_primitive_restart
<alyssa>
not really an option in vk.
<alyssa>
(unless I rewrite things with a cs.. still needs some funny memory allocation)
<alyssa>
ok, load_reg coalescing works now
<alyssa>
with almost no changes for the backend
<alyssa>
store_reg I need to give more thought
<alyssa>
and probably do a similar validation/lowering as above but in reverse
Leopold__ has quit []
<karolherbst>
sooo.. is nir_lower_mem_access_bit_sizes the fancy pass now I can use to lower all vec8/16 to vec4?
Leopold_ has joined #dri-devel
<karolherbst>
just uhm... I know what to do for like next week
<jenatali>
Yes
<karolherbst>
nice
<karolherbst>
I kinda want to ditch pointless vec8/16 code from backends again
<jenatali>
I'm going to be adding masked store support to it soon (for storing an 8bit var on hardware that doesn't support it, by doing 2 atomics)
dcz_ has quit [Ping timeout: 480 seconds]
<jenatali>
And then I can delete a whole crapload of custom code and a few custom intrinsics
<karolherbst>
fancy
<alyssa>
"storing an 8bit var on hardware that doesn't support it, by doing 2 atomics"
<alyssa>
thanks I hate it
<jenatali>
Yeah
<jenatali>
DXIL doesn't have 8bit support
<jenatali>
CL requires it :(
<alyssa>
atomic_xor(0xFF) + atomic_or?
<jenatali>
So does DOOM Eternal in Vk
<alyssa>
er wait
<alyssa>
atomic_and(0xFF00) + atomic_or?
<jenatali>
Yep
<alyssa>
still seems vaguely racey
<karolherbst>
why doesn't it have 8 bit support...
<jenatali>
Yeah, if you have a race on the same byte you can get garbage. The alternative is a cmpxchg loop for every store
<alyssa>
yeah..
<jenatali>
karolherbst: Good question
<alyssa>
any good answer? :P
<karolherbst>
I kinda understand if the alu can't do it, but for memory load/stores? mhh
<jenatali>
No, there's no good answer
<jenatali>
Nobody asked for it really until we did CL, and then our DXC team has been busy ever since
<karolherbst>
is it worse than some company saying "no int8 or no dxil with us"
<jenatali>
We still don't have scalar UBO layouts, which people are actually asking for...
<anholt_>
man, it's really easy to pass ARB_fp fog tests when we don't actually have any.
<karolherbst>
I still don't understand why modern APIs just don't see memory as blob of bytes
<Company>
no int8 or no dxil with us
<alyssa>
lol
Haaninjo has quit [Quit: Ex-Chat]
<airlied>
jenatali: should just move to vulkan :-P
* airlied
wonders how many lawyers saying that could summon
Lynne has quit [Remote host closed the connection]
Lynne has joined #dri-devel
<alyssa>
:~)
jluthra has joined #dri-devel
onox[m] has joined #dri-devel
gallo[m] has joined #dri-devel
pcercuei has quit [Quit: Lost terminal]
DUOLabs[m] has joined #dri-devel
crabbedhaloablut has quit [Read error: Connection reset by peer]
crabbedhaloablut has joined #dri-devel
crabbedhaloablut has quit [Read error: Connection reset by peer]
crabbedhaloablut has joined #dri-devel
Hi-Angel has joined #dri-devel
apinheiro has quit [Quit: Leaving]
Eighth_Doctor has joined #dri-devel
smiles_1111 has joined #dri-devel
moben[m] has joined #dri-devel
LinuxHackerman has joined #dri-devel
ngcortes_ has joined #dri-devel
yshui` has joined #dri-devel
ram15[m] has joined #dri-devel
<jenatali>
alyssa: Congrats!
ngcortes has quit [Ping timeout: 480 seconds]
dolphin has quit [Remote host closed the connection]
dolphin has joined #dri-devel
Jeremy_Rand_Talos has quit [Remote host closed the connection]