<daniels>
yeah, it looks like the hardware just died
tlwoerner has quit [Quit: Leaving]
tlwoerner has joined #dri-devel
Company has joined #dri-devel
eukara has joined #dri-devel
<robclark>
karolherbst: looks like a630-traces died 3 times in a row the same way, so I guess there is something wrong with the MR?
<robclark>
different runners each time too
<robclark>
so looking like a legit problem
mbrost has quit [Remote host closed the connection]
mbrost has joined #dri-devel
<robclark>
karolherbst, daniels: err, hmm.. actually looking at the raw results.. piglit still claims "pass" despite freedoom gpu hang.. so maybe infra problem?
<robclark>
friday evening in europe, I guess that is the normal time for infra problems
<daniels>
oh, I see what's happened
<daniels>
23-11-03 14:37:10 R SERIAL-CPU> hwc: mesa: pass
YHNdnzj[moz] has joined #dri-devel
<daniels>
that's the last thing in the init script before it sleeps
<daniels>
bm looks for 'hwci: mesa: pass' to terminate
<daniels>
maybe we should just echo that out like 3x to make sure it gets through
<robclark>
heh, the earlier ones: hwci:���sa: pass
<robclark>
and: hwc: mesa: pass
<daniels>
uart \o/
<robclark>
how does it manage to drop/garble a character three times in a row, exactly there!
<robclark>
but yeah, maybe just echo it a few times at the end
<daniels>
I wonder if we should make bm use SSH for console like LAVA does now
<gfxstrand>
daniels: FYI: The NAK MR is literally just waiting for meson 1.3.0rc2 to be tagged. As soon as that tag exists and propagates to pip, I can make a 2-line change and it should go through fine.
<gfxstrand>
But I don't control that. I'm hopping they tag today.
<daniels>
gfxstrand: sure thing, do you need anything from me?
<gfxstrand>
Nope
<daniels>
coolio
<gfxstrand>
If another container build fails, I'll poke you. Otherwise, I'm just waiting for the tagl.
<daniels>
bonne chance
<gfxstrand>
*tag
alyssa has quit [Quit: alyssa]
mbrost has quit [Ping timeout: 480 seconds]
jeeeun8413519 has joined #dri-devel
vliaskov has quit [Ping timeout: 480 seconds]
vliaskov has joined #dri-devel
MrCooper has quit [Remote host closed the connection]
alanc has quit [Remote host closed the connection]
alanc has joined #dri-devel
jenatali has joined #dri-devel
Guest5651 is now known as DemiMarie
<jenatali>
gfxstrand: Any more comments on !25998?
bmodem has quit [Ping timeout: 480 seconds]
<robclark>
gfxstrand: is the meson dependency bump _only_ if you are building nvk? Or across the board?
<gfxstrand>
robclark: Only for NVK
<gfxstrand>
robclark: But it means we need to bump the version in CI
<robclark>
coolio.. was just wondering if I'd need to uprev meson in CrOS but sounds like I dodge that bullet :-P
<gfxstrand>
Not unless you're shipping NVK on an NVIDIA chromebook you haven't told me about. 😅
<robclark>
well, at least for mesa-freedreno uprev, I don't need to enable nvk :-P
<gfxstrand>
So you're saying there is an NVK chromebook? :P
<gfxstrand>
If so, don't you think that's a tad presumptuous? I mean, Fedora did it so why not google. ¯\_(ツ)_/¯
<robclark>
well, the thing with the nv dGPU is no more... but if there ever is something w/ nv in the future, I think most folks here would strongly prefer to ship nvk ;-)
FloGrauper[m] has joined #dri-devel
YaLTeR[m] has joined #dri-devel
gallo[m] has joined #dri-devel
Calandracas_ has joined #dri-devel
<Calandracas>
Trying to compile mesa with llvm17, build is failing on gallium/auxiliary/gallivm/lp_bld_init.c because llvm-c/Transform/Scalar.h does not exist. It appears that the C bindings for some of the "Transforms" headers have been removed
Calandracas_ has quit []
mbrost has joined #dri-devel
lynxeye has quit [Quit: Leaving.]
heat_ has joined #dri-devel
mbrost has quit [Ping timeout: 480 seconds]
heat has quit [Read error: No route to host]
<DavidHeidelberg>
Calandracas: I have feeling I saw MR which addresses this issue
<Company>
is there a recommended way to measure libGL overhead in a profiler so I can optimize the right stuff? When I run stuff - even with mesa_glthread=false exported - most of the work ends up in a thread
<Company>
and then the flamegraph isn't useful
<robclark>
if the driver supports threaded ctx (which iris and radeonsi do) then add `GALLIUM_THREAD=0`
<Company>
that *and* mesa_glthread=false seems to do the trick
<Company>
seems the magic is batching which will require tracking texture usage across commands, and that's all about using an atlas for all the icons and glyphs so it's the same texture everywhere
<Company>
interesting because Vulkan doesn't seem to need that, vkCmdDraw has a way smaller overhead
djbw has quit [Read error: Connection reset by peer]
MayeulC has joined #dri-devel
<robclark>
binding new texture state between every draw is probably not great.. radeonsi does support bindless textures which would make things more like vk (but iris and others do not)
heat_ has quit [Remote host closed the connection]
heat_ has joined #dri-devel
Kwiboo has quit [Quit: .]
cos has quit [Remote host closed the connection]
<Company>
yeah, I'm using a glSampler2D textures[N_TEXTURES]; array and now basically doing 3 "levels" - one doing constant expression texture accesses (read: large if statement), one doing dynamically uniform texture accesses and one doing bindless/nonuinform
<Company>
with the nonuniform stuff I can do 1 draw call for everything
<Company>
with the dynamically uniform I can do batch draw calls as long as they use the same texture
jkrzyszt has quit [Ping timeout: 480 seconds]
<Company>
and with constants I need to setup texture units before each draw call with different textures
Kwiboo has joined #dri-devel
<Company>
just need to get it right...
<robclark>
I'd dynamically index the texture array over if/else ladder
<Company>
yeah, that's what I'm doing
<Company>
but it's a bit of a question how many entries I want to put there
q4a has joined #dri-devel
<robclark>
I think max is 32.. put as many as you can if it avoids state changes
tursulin has quit [Ping timeout: 480 seconds]
reactormonk[m] has joined #dri-devel
<Company>
I think I read the spec and it says "has to be at least 32", but may be as much as GL_MAX_SOME_CONSTANT
<CounterPillow>
Though, refresh rate is a bit fiddly to figure out since that depends on your SPI controller speed and the maximum speed the SPI chain LEDs can work at.
oneforall2 has quit [Remote host closed the connection]
K0bin[m] has joined #dri-devel
Duke`` has quit [Ping timeout: 480 seconds]
Vin[m] has joined #dri-devel
apinheiro has quit [Quit: Leaving]
<mriesch>
CounterPillow: afaik there is fbdev panel and DRM panel, right? any thoughts on this choice?
mvlad has quit [Remote host closed the connection]
oneforall2 has joined #dri-devel
jkhsjdhjs has quit [Ping timeout: 480 seconds]
i509vcb has joined #dri-devel
tobiasjakobi has joined #dri-devel
jkhsjdhjs has joined #dri-devel
heat has joined #dri-devel
heat_ has quit [Read error: Connection reset by peer]
kusma has joined #dri-devel
Haaninjo has quit [Quit: Ex-Chat]
tobiasjakobi has quit []
nyorain[m] has joined #dri-devel
mbrost has joined #dri-devel
glennk has quit [Ping timeout: 480 seconds]
mbrost has quit [Ping timeout: 480 seconds]
<cwabbott>
gfxstrand: ok, it turns out that I was lucky, the NaN canonicalization while copying was entirely due to sample() and if I use texelFetch() instead and be careful about using a half-reg for f16 formats (to avoid the f16->f32->f16 roundtrip also canonicalizing) then I can avoid any of it
<cwabbott>
it'll mean we can't use the special 2d path that always does sample(), but that's probably fine
<cwabbott>
crisis averted
<cwabbott>
ughhhh some r16_unorm tests are still failing
<cwabbott>
snorm works but not unorm?!?
sima has quit [Ping timeout: 480 seconds]
mbrost has joined #dri-devel
<cwabbott>
nvm, my bad
treeq[m] has joined #dri-devel
lcn has quit [Read error: Connection reset by peer]
<cwabbott>
dEQP-VK.api.copy_and_blit.core.image_to_image.all_formats.color.2d_to_2d.* all pass now \o/
hrushi20 has quit [Ping timeout: 480 seconds]
hrushi20 has joined #dri-devel
mbrost has quit [Remote host closed the connection]
mbrost has joined #dri-devel
<Kayden>
karolherbst: the 36-bit thing has been there since 2012...but I'm not sure how much sense it actually makes these days. f0159018d7709b57d9916575512d75cb3f2fb395 ... the thinking was that opengl programs used GL_QUERY_COUNTER_BITS to assume things rolled over at a power of two, and so when we scaled the 32-bit timestamp value by the tick frequency to get actual nanoseconds, it'd roll over at...some other time. so we tried to find something workable
<Kayden>
but nowadays the time scaling is done by various fractional things and so I'm not sure it works out anyway
<karolherbst>
yeah...
<karolherbst>
makes sense
<karolherbst>
all I can say is, that I have CL CTS flakes caused by that
<Kayden>
hmm, actually it looks like it may be a 36-bit signal nowadays...
sigmoidfunc[m] has joined #dri-devel
<karolherbst>
Kayden: okay, so inside a shader there is just 36 bit of precision anyway?
<Kayden>
oh, inside a shader........as I understand it our timestamp register used for ARB_shader_clock is pretty much garbage and doesn't work most of the time anyway
<karolherbst>
pain
<karolherbst>
In CL there is no way to fetch the timestamp in a kernel anyway, I was just curious because I thought `signal` is a shader thing on intel
<Kayden>
I don't remember the details - curro did a lot of work to measure instruction timings using it. he would probably remember the details of how it's broken, but it was a pretty huge list
<Kayden>
I think it might've reset on thread switches or power management events or something absurd like that
<karolherbst>
uhh
<karolherbst>
annoying...
<karolherbst>
well
<Kayden>
I think the one you get via PIPE_CONTOL or the Timestamp register (read from the command stream) is a lot more reliable
<karolherbst>
all I use are `get_timestamp` and PIPE_QUERY_TIMESTAMP
<karolherbst>
PIPE_CONTOL? that's something I've never heard of