ChanServ changed the topic of #dri-devel to: <ajax> nothing involved with X should ever be unable to find a bar
pcercuei has quit [Quit: dodo]
Haaninjo has quit [Quit: Ex-Chat]
nsneck has joined #dri-devel
iive has quit []
Lucretia has quit [Ping timeout: 480 seconds]
ppascher has quit [Ping timeout: 480 seconds]
krushia has joined #dri-devel
ppascher has joined #dri-devel
heat has joined #dri-devel
ybogdano has quit [Ping timeout: 480 seconds]
soreau has quit [Read error: Connection reset by peer]
soreau has joined #dri-devel
mclasen has quit [Ping timeout: 480 seconds]
tursulin has quit [Remote host closed the connection]
ahajda has quit [Quit: Going offline, see ya! (www.adiirc.com)]
<imirkin>
zmike: all i can say is that stuff is super-subtle. i'll have a closer look at what the test is doing. do you believe the test is wrong or mesa is wrong (or some happy combination)?
<zmike>
ccr: hey cool, will check tomorrow
<imirkin>
fwiw the test does (did!) pass before. unfortunately the GPUs i have plugged in right now don't support per-texture seamless cubemap settings
<zmike>
imirkin: pretty sure mesa's wrong
<zmike>
the test does pass still
<zmike>
but I don't know how it's passing for anyone
<zmike>
it shouldn't
<imirkin>
hehe ok
<imirkin>
will try to have a closer look ... maybe later tonight, if the alcohol doesn't hit too hard
<zmike>
I dug pretty deep and it looks like some weird conflation of "current" sampler and targeted sampler
<zmike>
and that state isn't propagating
<zmike>
yea sure, no rush
<zmike>
I think you don't actually need a gpu that supports the feature to see the issue
<Sachiel>
alcohol sounds like a great way to make cubes look seamless
<zmike>
hahah
<zmike>
if you enable the pipe cap you can just check the flag on the sampler state that gets bound and see that it's wrong
<imirkin>
zmike: ok. both of the ones i have plugged in _do_ have seamless support. and i guess llvmpipe supports seamless too
<zmike>
even easier
<imirkin>
(fun fact - half of the nvidia tesla gen doesn't support seamless, and yet they advertise GL 3.3 on them)
<imirkin>
(another fun fact -- trying to use texture() on a samplerCubeShadow with bias ends in a compile error with the nvidia blob. with nouveau we just ignore the bias)
<zmike>
grimace
<imirkin>
[on tesla gpu's that is... fermi+ it's all good]
pnowack has quit [Quit: pnowack]
<imirkin>
zmike: apologies for the idiotic question, but ... which draw is the 4th draw, per your bug?
<zmike>
uhhhhhhhhh
<imirkin>
you mean the literal 4th draw_quad() invoc?
<zmike>
yeah
<imirkin>
ok cool
<zmike>
I was editing it as I went to debug
<imirkin>
i see. and it's the first one after the previous one set the texparam to true
<imirkin>
but the texparam is now false.
<imirkin>
time to go rtfs (s = spec)
<imirkin>
ok right. it works the way i thought. the global and per-texture thing is OR'd together
co1umbarius has joined #dri-devel
<imirkin>
(or at least is meant to be)
<zmike>
that's my understanding too
columbarius has quit [Ping timeout: 480 seconds]
<zmike>
but in this case the global state is false and the in-use texture unit was previously false, so no state change occurs
<zmike>
but it still uses the state from the previously-used tex unit, which was true
<imirkin>
yea, checking over that
<zmike>
and thus...how does this work for anyone?
<imirkin>
step 1 is for me to confirm your findings. if that pans out, could be the test isn't as sensitive as it could be
ngcortes has quit [Remote host closed the connection]
ella-0_ has joined #dri-devel
ella-0 has quit [Remote host closed the connection]
Bennett has quit [Remote host closed the connection]
ngcortes has quit [Remote host closed the connection]
heat_ has joined #dri-devel
heat has quit [Read error: No route to host]
heat_ has quit []
mhenning has quit []
macromorgan has quit [Quit: Leaving]
i-garrison has quit [Ping timeout: 480 seconds]
macromorgan has joined #dri-devel
i-garrison has joined #dri-devel
maxzor has joined #dri-devel
maxzor has quit [Remote host closed the connection]
maxzor has joined #dri-devel
camus1 has joined #dri-devel
camus has quit [Ping timeout: 480 seconds]
<zmike>
anholt: just put up a MR which may or may not greatly reduce zink ci time
<zmike>
a real 🤔 moment
camus has joined #dri-devel
<airlied>
zmike: from memory the gles3 tests don't include gles2
<airlied>
the runner runs both
<zmike>
you sure? I was getting the same fails
<airlied>
tripped me up when I went to get llvmpipe gles 3.2, and realised I had to pass gles2 first
<airlied>
you dropped some dEQP-GLES2 fails from the fail list though
<zmike>
I guess I'll check the mustpass lists tomorrow
camus1 has quit [Read error: Connection reset by peer]
<zmike>
yea I dropped tehm because they're the same
<airlied>
yeah it also might have changed, but I ran into it before
<zmike>
the only gles2 fails I have are also in the 3.x list
<airlied>
I never worked out how to implement the other style of point clipping back then so I gave up my gles dreams
<zmike>
points are the worst
<airlied>
wtf is debian-vulkan build failing for everyone?
<HdkR>
GLES only matters if you care about Android so it's fine right? ;)
<airlied>
I only care about numbers getting higher on mesamatrix :-P
<airlied>
ah musta been a once off rebuild seems fine
<airlied>
bouncing to marge for another go
kts has quit [Quit: Konversation terminated!]
shankaru has joined #dri-devel
i-garrison has quit []
i-garrison has joined #dri-devel
i-garrison has quit []
i-garrison has joined #dri-devel
jewins has quit [Read error: Connection reset by peer]
jewins has joined #dri-devel
<imirkin>
zmike: so ... one observation about that test is that it uses glBegin/glEnd. this has funny effects on state management. could be a FLUSH_VERTICES missing somewhere
Duke`` has joined #dri-devel
<imirkin>
also there appears to be some sort of batching thing going on. there are 16 draws in the program, but i only see draw getting called 8x. but i don't see how any such batching would be legal since the texture changes each time (even forgetting about the seamless flag)
<imirkin>
both textures have the same data
i-garrison has quit []
<imirkin>
but it's not like the draw merge thing knows about that...
<imirkin>
(but it explains why the test passes anyways)
i-garrison has joined #dri-devel
itoral has joined #dri-devel
fxkamd has quit []
jewins has quit [Ping timeout: 480 seconds]
danvet has joined #dri-devel
<imirkin>
zmike: ok, so for reasons which aren't wholly clear to me, texture "1" is somehow invalid
<imirkin>
this leads to all kinds of further shenanigans
<imirkin>
at some point, the piglit framework sets up texture 1 as GL_TEXTURE_2D and i guess there's no way back
mattrope has quit [Ping timeout: 480 seconds]
mlankhorst has joined #dri-devel
<danvet>
robclark, yeah I guess if all your de-dup needs are covered by the guest kernel handling duped imports then it should work
<danvet>
probably needs a pretty huge uapi warning though since I'm sure people will see this and think it's cool and all :-)
Duke`` has quit [Ping timeout: 480 seconds]
frieder has joined #dri-devel
kts has joined #dri-devel
eukara has quit []
alanc has quit [Remote host closed the connection]
alanc has joined #dri-devel
maxzor has quit []
mlankhorst has quit [Ping timeout: 480 seconds]
linearcannon has joined #dri-devel
MajorBiscuit has joined #dri-devel
sarnex has quit [Ping timeout: 480 seconds]
tzimmermann has joined #dri-devel
mszyprow has joined #dri-devel
mlankhorst has joined #dri-devel
ahajda has joined #dri-devel
rgallaispou has joined #dri-devel
tursulin has joined #dri-devel
sarnex has joined #dri-devel
eukara has joined #dri-devel
maxzor has joined #dri-devel
<emersion>
seems like radv_stoney_vkcts (mesa-lava-collabora-hp-11A-G6-EE-grunt) is borked
laraaj has quit [autokilled: This host violated network policy. Contact support@oftc.net for further information and assistance. (2022-02-15 09:32:38)]
padovan has joined #dri-devel
pnowack has joined #dri-devel
eukara has quit [Remote host closed the connection]
<dj-death>
trying to make use of the printf pass in NIR
<dj-death>
seems like the atomic counter at the beginning of the buffer is overwritten by the first printf data element
<dj-death>
just wondering whether the problem exists in clover too or if I'm doing something wrong
maxzor has quit [Ping timeout: 480 seconds]
flacks has quit [Quit: Quitter]
flacks has joined #dri-devel
nchery is now known as Guest439
nchery has joined #dri-devel
camus1 has joined #dri-devel
Guest439 has quit [Ping timeout: 480 seconds]
camus has quit [Ping timeout: 480 seconds]
nchery has quit [Read error: Connection reset by peer]
<daniels>
emersion: yeah thanks for pointing out, I've got a fix to catch that and retry, just need to test and push
JoniSt has joined #dri-devel
itoral has quit [Remote host closed the connection]
itoral has joined #dri-devel
maxzor has joined #dri-devel
devilhorns has joined #dri-devel
kts has quit [Quit: Konversation terminated!]
itoral has quit [Remote host closed the connection]
itoral has joined #dri-devel
maxzor_ has joined #dri-devel
nchery has joined #dri-devel
maxzor_ has quit [Ping timeout: 480 seconds]
Rabbitz has quit []
mvlad has joined #dri-devel
mclasen has joined #dri-devel
itoral has quit [Remote host closed the connection]
itoral has joined #dri-devel
itoral has quit [Remote host closed the connection]
itoral has joined #dri-devel
Lucretia has joined #dri-devel
heat has joined #dri-devel
itoral has quit [Remote host closed the connection]
itoral has joined #dri-devel
itoral has quit [Remote host closed the connection]
Major_Biscuit has quit [Ping timeout: 480 seconds]
Major_Biscuit has joined #dri-devel
sdutt has joined #dri-devel
MajorBiscuit has joined #dri-devel
Major_Biscuit has quit [Ping timeout: 480 seconds]
fxkamd has joined #dri-devel
mattrope has joined #dri-devel
jewins has joined #dri-devel
<jenatali>
dj-death: The result of the atomic on the counter is supposed to indicate where in the buffer to write. Sounds like your atomic is somehow returning 0?
<dj-death>
jenatali: ah okay, so the buffer should be initialized with 4
<dj-death>
jenatali: like put the data right after the atomic counter
bluebugs has joined #dri-devel
pcercuei has quit [Remote host closed the connection]
<dj-death>
it's all a bit weird with +1 string indices...
<jenatali>
I don't remember why we did that. Been a long time since I wrote most of that code
fxkamd has quit []
<bbrezillon>
jekstrand: I'm trying to debug dEQP-VK.glsl.linkage.varying.struct.float, which wraps a float inside a struct and pass it from the VS to FS. AFAIU, the problem is that DXIL wants raw types (int/float vectors) for varyings
<bbrezillon>
jekstrand: I thought nir_split_per_member_structs would do the trick, but it's only splitting blocks, not structs, and as you pointed out, I'd still have to split array of structs anyway
<calebccff>
For context, with the logging enabled the idling behaviour looks like this whilst navigating UI: https://p.calebs.dev/17fa74
<jekstrand>
bbrezillon: Does it allow arrays?
<robclark>
calebccff: maybe we should just add min-idle-time to `struct adreno_info`? The one thing is we might want to do some delayed-work thing instead because if there isn't another active->idle transition nothing will reduce the freq until devfreq governor kicks in
<jenatali>
bbrezillon: Is it trying to interpolate the float? Or just pass it flat? I got structs passing (just treating them as uint4s) for GL relatively recently, as part of the fp64 series
<calebccff>
robclark: ah so just adjust the queue_work() call to have a 100ms delay for a630?
<robclark>
yeah
<calebccff>
looking at my logs again, you're right about idle not being called again :X
<calebccff>
Thanks, I'll rework the patch
<robclark>
np, thx for looking into that
<bbrezillon>
jenatali: nir_to_dxil seems to treat the struct as an int (it doesn't seem to be split in basic elems)
<bbrezillon>
and then apply an linear-interpolation
<bbrezillon>
which is rejected
<calebccff>
robclark: how would I go about pulling the struct adreno_info out of struct msm_gpu?
<jenatali>
bbrezillon: so the shader is actually trying to interpolate the float?
<bbrezillon>
interpolation == INTERP_MODE_NONE
<bbrezillon>
which we map to LINEAR
Duke`` has joined #dri-devel
<robclark>
calebccff: hmm, it is in adreno_gpu .. but maybe the idle-delay should just be copied into msm_gpu
<bbrezillon>
don't know if it's allowed to have different interpolation on struct members though
<robclark>
calebccff: also, did you see the gdsc delay patch? I was kinda wondering if something like that could be behind the a630 issue.. bamse looked at it a bit and I think one of the delay values was wrong, but maybe wasn't helping
<jenatali>
bbrezillon: Not sure of that NONE -> LINEAR is the right mapping. If it is, maybe we say that flat structs are uints, and interpolated structs are floats? :)
<jenatali>
Or maybe NONE -> LINEAR for floats, and NONE -> FLAT for structs or ints
<bbrezillon>
so I was trying to split structs instead
<bbrezillon>
what if you have floats inside the struct?
<jenatali>
The tests/spec should be able to tell us (or maybe jekstrand just knows) whether floats in a struct can be interpolated. My guess is no, only top-level float vecs/arrays can be interpolated
<calebccff>
robclark: huh i see, looks interesting... It does look like it could potentially be related to the issue. Thanks
pnowack has quit [Quit: pnowack]
<jekstrand>
floats in structs can get interpolated, I'm pretty sure.
<bbrezillon>
yep, at least that's what they say for flat/no-perpective interp
<bbrezillon>
linear interpolation is the default IIUC
<jekstrand>
Right... I'm remembering now.
<jekstrand>
Interpolation qualifiers can only go on the top-level block or on members of it. You can't decorate a sub-struct.
<jekstrand>
spirv_to_nir will make a splittable variable and nir_split_per_member_structs will split it.
<jekstrand>
The result is that the interpolation qualifier in NIR is per-variable.
<jekstrand>
So, yeah, you can float/int the whole thing based on interpolation. That should be fine.
<bbrezillon>
but what happens if you have linear interp on the struct, and this struct contains ints and floats
<HdkR>
Watch out for interpolation qualifier inheritence. That'll bite you :)
<HdkR>
Apple's OpenGL shader compiler does it wrong as an interesting point.
<bbrezillon>
and by linear, I mean unspecified interpolation, since it seems to be the default
<jekstrand>
Right... I think the ints are ignored, maybe.
* jekstrand
reads the GLSL spec
<HdkR>
inheritence rules. they'll have linear applied unless you explicitly override
* bbrezillon
couldn't find anything clear in the GLSL spec :-/
<HdkR>
Which of course results in compile error
<jekstrand>
We're safe!
<jekstrand>
"
<jekstrand>
Fragment shader inputs that are, or contain, integral or double-precision floating-point types must be qualified with the interpolation qualifier flat.
<jekstrand>
"
<jekstrand>
That's GLSL, anyway
* jekstrand
looks at Vulkan
<HdkR>
ah, doubly resolves the issue :D
<bbrezillon>
ok, that would definitely save us
<jekstrand>
Vulkan also has a VU:
<jekstrand>
VUID-StandaloneSpirv-Flat-04744
<jekstrand>
Any variable with integer or double-precision floating-point type and with Input storage class in a fragment shader, must be decorated Flat
<bbrezillon>
ok, so that means I should map structs to floats if interp == none
<jekstrand>
Sounds like, yes.
<dj-death>
jenatali: fun times, with the options->treat_doubles_as_floats
<dj-death>
jenatali: because it leaves the arg size at 8bytes in the nir_printf_info::arg_sizes
cworth has quit [Ping timeout: 480 seconds]
<jenatali>
Yep, I'm aware. It was a bit of a hack
<dj-death>
I guess the intrinsic could take a const offset
<dj-death>
for the string id
<dj-death>
jenatali: does that sound crazy?
lemonzest has joined #dri-devel
<jenatali>
dj-death: sounds fine I think
pnowack has joined #dri-devel
cworth has joined #dri-devel
ybogdano has joined #dri-devel
<JoniSt>
I'm looking through u_threaded_context at the moment and I'm a bit confused... What stops tc_batch_flush from just filling the entire batch/buffer ring buffers when tc_add_sized_call gets called a lot?
idr has joined #dri-devel
heat has quit [Read error: Connection reset by peer]
heat has joined #dri-devel
eukara has joined #dri-devel
<dj-death>
jenatali: well hang on, it's writing 4bytes for doubles but offsetting at 8 ;)
<jenatali>
Right. My goal was to eliminate the float -> double casts and just write the float directly
<jenatali>
If you only support floats, it's simple enough to set that bit and parse %f as a float with 4 bytes of padding. Otherwise all %f will be doubles
<dj-death>
well not really it seems
<dj-death>
because the write offsets are based of doubles
<dj-death>
but the writing uses floats
<dj-death>
oh sorry
<jenatali>
Yeah, it's like a union { float f; double d; }; where the f is written
<dj-death>
I missed your 4 bytes of padding
<dj-death>
yeah I need to did into what's wrong
<dj-death>
because floats are messing up the next string id in the buffer
<jenatali>
dj-death: I don't think clover ever sets that bit today. That lowering pass is also used for CLOn12 which uses a different path to get at the compiler and data
Lucretia has quit []
Lucretia has joined #dri-devel
shankaru has quit [Quit: Leaving.]
gouchi has joined #dri-devel
gawin has joined #dri-devel
MajorBiscuit has quit [Quit: WeeChat 3.4]
<JoniSt>
Ah, nevermind, I figured it out. Looks like the threaded_context u_queue size is limited so that the batch ring buffer is just big enough. Tricky stuff...
<bbrezillon>
jenatali, jekstrand: thanks for your help, I have all the dEQP-VK.glsl.linkage.varying.* tests passing now
<jenatali>
bbrezillon: \o/
JohnnyonFlame has quit [Remote host closed the connection]
<cmarcelo>
gallium and two vulkan drivers (anv, v3dv) use the "vec3 is vec4 aligned" layout for shared memory. spirv_to_dxil and other vulkan drivers (radv, lvp, tu) don't use this restriction.
<cmarcelo>
as part of making helper for this, I'm trying to figure if we can live with one layout (the same as gallium) for everyone, or is better have 2 helpers, one for each behavior.
<cmarcelo>
(right now each driver has a helper of their own locally defined)
<calebccff>
robclark: So implementing your change, the idle work never seems to actually run because it always gets cancelled in <100ms, either by an active transition or by devfreq going into idle. I thought this was because calling queue_work() resets the timer, but even only queuing if it's not already active didn't help
<robclark>
calebccff: yeah, we might need to make the timeout something like max(1ms, min_active_duration - time_since_last_transition_to_active)
<calebccff>
robclark: hm ok, does msm_devfreq_suspend() also cause dev_pm_qos_update_request() to be called (via devfreq ?)?
<calebccff>
or do we need to make sure msm_devfreq_idle_work() happens before devfreq_suspend()?
<robclark>
msm_devfreq_suspend() cancels idle work.. or.. well, I guess there are some patches in that area which haven't ended up in a pull request yet
<calebccff>
robclark: i do have both of those, so i think they're in mainline
alyssa has joined #dri-devel
* alyssa
stares at Kconfig
<calebccff>
but yeah msm_devfreq_idle_work() is never being called, so it's always being cancelled. Would it be suitable to add "dev_pm_qos_update_request(&df->idle_freq, 0);" to msm_devfreq_suspend()?
<alyssa>
how do I express that if both ARCH_MEDIATEK and DRM_PANFROST are enabled, MTK_INFRACFG *must* be enabled
<alyssa>
I guess DRM_PANFROST would get
<calebccff>
or perhaps combine both attempts, but instead of rejecting the idle if it's been <100ms, just re-queueing the work to happen when it has been 100ms, that way it will always idle
<alyssa>
select MTK_INFRACFG if ARCH_MEDIATEK?
<alyssa>
or, err, depends on?
<alyssa>
er, no, `depends on MTK_INFRACFG is ARCH_MEDIATEK`
<alyssa>
I guess select
<bbrezillon>
jekstrand: ok, next problem, DXIL doesn't like overlapping inputs in VS, can we relax the assert() in nir_lower_io_to_vector_impl() so I can use this pass on VS inputs too?
<bbrezillon>
or are there pitfalls with input vectorization on VS shaders
<bbrezillon>
?
<anarsoul>
alyssa: select MTK_INFRACFG if ARCH_MEDIATEK
<alyssa>
anarsoul: ack, thanks
yogesh_mohan has quit [Ping timeout: 480 seconds]
<alyssa>
not 100% sure it's necessary but may add that line to the stack
<calebccff>
the device goes to qualcomm crashdump mode after the above error
<robclark>
hmm, :-(
<robclark>
I guess the problem is actually in the increasing-the-freq direction
<calebccff>
this does seem to point to the issue not being what I originally thought if it's reproducible like this. Althought that doesn't explain how my first patch was able to work
<calebccff>
unless it just made it harder to reproduce
<calebccff>
as with this it idles much more often than with my first approach earlier
tzimmermann has quit [Quit: Leaving]
yogesh_mohan has quit [Ping timeout: 480 seconds]
<robclark>
yeah, I think it isn't really addressing the root issue
heat has quit [Read error: No route to host]
heat has joined #dri-devel
<graphitemaster>
So when we getting GL 4.7
devilhorns has quit []
<JoniSt>
graphitemaster: Pretty sure that's called Vulkan
<bbrezillon>
jekstrand: hm, nevermind, vectorization doesn't happen if there's a component that's not used in the middle of a vec4, so we'll have to take care of this merge in the backend I guess
camus1 has quit [Remote host closed the connection]
camus has joined #dri-devel
ngcortes has joined #dri-devel
pnowack has quit [Quit: pnowack]
yogesh_mohan has joined #dri-devel
mszyprow has quit [Ping timeout: 480 seconds]
Jonathan_Cavitt has joined #dri-devel
karolherbst_ has joined #dri-devel
gawin has joined #dri-devel
karolherbst has quit [Ping timeout: 480 seconds]
iive has joined #dri-devel
Haaninjo has joined #dri-devel
pnowack has joined #dri-devel
dllud has joined #dri-devel
dllud_ has quit [Read error: Connection reset by peer]