<Kayden>
that'll teach me to copy curly quotes from the vulkan spec
<pinchartl>
that would teach me to use windows :-)
<pq>
tlwoerner, marex, didn't Fedora get the seamless bootsplash hand-over from firmware->bootloader->plymouth->displayserver alraedy working? So, expand on that? Now who was the one working on that... I almost remember the same
mvlad has joined #dri-devel
<javierm>
pq: that's correct and I think ubuntu also has the same
<javierm>
pq: and that's why I mentioned BGRT support in u-boot's EFI, since that would give us the same experience for aarch64 devices using u-boot (i.e: the pinephone)
<pq>
the name, the name, I think it had a j in it...
<Kayden>
I think most of those are old, and some of those folks aren't around or mentoring anymore
<Kayden>
but we should at least not send anyone toward freenode anymore :/
<maxzor>
What is the xorg foundation about today? In some occasions it appears to be a chaperone for all the FLOSS GPU stacks, and in some others, it is branded as just about the x window system still
<maxzor>
https://www.x.org/wiki/ this does not mention wayland, egl..., yet the wiki hosts the above gsoc page
<maxzor>
even this dri-devel channel has a topic mentioning x only, but is home to the whole GPU community
<maxzor>
A few weeks ago I was looking for a way to get sponsored at Gsoc to advance ROCm RADV interop, I reached out to the Blender foundation and to Brian Savery at AMD, but it was not at all obvious to me at that time that I should have looked at xorg for sponsors
rasterman has joined #dri-devel
<Venemo>
maxzor: DRI means direct rendering infrastructure, so the channel is about all aspects of GPU drivers and such
<maxzor>
Venemo, but when you browse wikipedia, you find out that the last dri release was in 2009, and you get routed to Mesa and KMS/DRM. I'm really just complaining about the ease of discovery of this community. I'll look into the kunit amdgpu topic, but the next individual may experience the same sort of troubles
<Venemo>
maxzor: I see.
<pq>
maxzor, maybe you are confusing x.org project and x.org foundation, which are... confusing
<pq>
maxzor, that seems to talk about the DRI that is an X11 protocol extension.
<pq>
DRI is an awfully overloaded term
<maxzor>
Ah I see, so petition to promote the xorgfoundation page as homepage for the x.org/wiki, instead of the xorg project
<pq>
DRI can also refer to the infratructure as in the acronym, in which it covers pretty much everything that is related to using GPUs on Linux (and BSD?)
<pq>
so kernel drivers, Mesa and all its drivers, Xorg, Xorg drivers, maybe even Wayland and compositors nowadays - that is the dri in #dri-devel
<pq>
DRI can also refer to some Mesa-internal APIs
Hi-Angel has quit [Ping timeout: 480 seconds]
tursulin has quit [Ping timeout: 480 seconds]
ella-0 has quit [Read error: Connection reset by peer]
kts has joined #dri-devel
devilhorns has joined #dri-devel
kts has quit [Quit: Konversation terminated!]
<ccr>
#dri-devel = The Ancient Secret Order of Graphics Stack Masons
<alyssa>
I still don't know why we don't split out #mesa
<alyssa>
though I guess anyone who works on Mesa long enough gets to enjoy WSI and the drm subsystem of the kernel too
<tjaalton>
hakzsam: hey, I'm not able to find your gpg key from any keyserver I tried..
itoral has quit [Remote host closed the connection]
itoral has joined #dri-devel
itoral has quit [Remote host closed the connection]
camus1 has joined #dri-devel
itoral has joined #dri-devel
<tlwoerner>
Kayden: thanks for updating the GSoC Ideas page
<tlwoerner>
pq: excellent, thanks for the info
itoral has quit [Remote host closed the connection]
camus has quit [Ping timeout: 480 seconds]
<tlwoerner>
maxzor: organizations that participate in GSoC are not sponsoring your work, they're mentoring it (potentially). the cheques come from Google
<tlwoerner>
alyssa: one firehose is better than two?
<alyssa>
tlwoerner: vroom vroom
lemonzest has joined #dri-devel
shankaru has quit [Quit: Leaving.]
<marex>
danvet: hey, is there some way to negotiate bus frequency between two bridges ? I need specific MIPI DSI frequency, since the bridge uses that to derive its own internal clock from it, and it must be one specific frequency and no other (oh well)
<marex>
danvet: I was thinking of something like .atomic_get_input_bus_fmts , maybe .atomic_get_input_bus_clocks ?
<marex>
danvet: and it really has to be the DSI bridge (sink) which decides the frequency and requests it from the DSI host (source)
<marex>
or is there something better ?
<marex>
daniels: ^
<daniels>
marex: I really don't know, sorry
<marex>
mripard: ^
<marex>
daniels: I might just implement a patch in that aspect and send it as RFC then
camus1 has quit []
dliviu has quit [Ping timeout: 480 seconds]
rgallaispou has quit [Ping timeout: 480 seconds]
<marex>
daniels: is there at least some design document on the format negotiation between bridges ?
<marex>
I think my overview is still limited
Company has joined #dri-devel
<daniels>
marex: I've never touched drm_bridge - I think pinchartl is who you want
<marex>
ah
<graphitemaster>
I find it ridiculous that GL/VK, D3D, and Metal could not agree on the layout of the draw indirect structure, MoltenVK actually runs a compute pass before every draw indirect to swizzle the damn parameters in the right layout order for Metal
<graphitemaster>
Interleaving draw and compute like that is so painful
<maxzor>
how much cycles do you loose with such a thing?
<graphitemaster>
Like why is this format so variable, does the hardware not have to go through a bunch of pain to support all these formats
<maxzor>
lose*
<graphitemaster>
Who knows, I'm just maulding over the fact APIs could not agree on the order of 5 integers
<graphitemaster>
We're doomed as engineers
<marex>
film at 11
* maxzor
notes that GPGPU has not been mentioned in the topics of the xorg foundation, nor #dri-devel
agd5f has joined #dri-devel
<graphitemaster>
If we had a good semantic for describing an indirect structure it would be very easy for the driver to rewrite the shader which writes the indirect parameters
<graphitemaster>
I wonder how much flow analysis is needed currently to derive that information as-is
<graphitemaster>
Probably impossible given modern APIs
<alyssa>
apparently it is merge day
<alyssa>
I apologize for hogging CI; willing to trade review bandwidth in exchange ;-p
<graphitemaster>
Who reviews PRs on a Friday
<graphitemaster>
This is a bad trade
<alyssa>
graphitemaster: in fairness who else is merging on a Friday, guess I can hog all I want? :-p
<pq>
maxzor, I guess no need to talk about GPGPU anymore when most rendering happens off-screen or even off-window-system anyway. E.g. EGL surfaceless/egl_device/gbm platforms.
<pq>
render nodes exist too
<graphitemaster>
alyssa, They get a sneaky merge in 30 seconds before end of the work day on a Friday and then everything breaks into the weekend.
<alyssa>
mood
sdutt has joined #dri-devel
<alyssa>
dschuermann: I guess I should be testing the thing I said I would test 3 months ago
<dschuermann>
alyssa: sounds good :) would love some improved FSR performance for the steam deck, although that won't happen within this week anymore
kts has joined #dri-devel
<alyssa>
Sorry :(
<alyssa>
admittedly i am supposed to be writing this essay due in.. uhm... 2 hours and 23 minutes
The_Company has joined #dri-devel
cafuffu has joined #dri-devel
Company has quit [Read error: Connection reset by peer]
jewins has joined #dri-devel
rgallaispou has joined #dri-devel
<alyssa>
dschuermann: both !12468 and !13080 need review?
mclasen has joined #dri-devel
<alyssa>
dschuermann: total cycles in shared programs: 202833.42 -> 199856.54 (-1.47%)
<alyssa>
dschuermann: i'll post a branch with my fixes when i'm done
<dschuermann>
alyssa: cool thx! the per-component DCE only makes sense on top of !13080. otherwise lowering to scalar already gives you that
<alyssa>
right, ok
<dschuermann>
I have to revisit that anyways. anholt found regressions using it
<alyssa>
!13080 regresses of course, trying with shrink stuff
<alyssa>
and so I saw :(
<alyssa>
so I guess we're not blocked on me after all :v
<dschuermann>
the per-component DCE gives you regressions as well? can you paste me an example? I would like to understand what happens
<alyssa>
the better vectorization series hurts instruction count without the shrink MR, but that was expected
<alyssa>
the per-component MR has basically no effect on its own
adjtm has joined #dri-devel
fxkamd has joined #dri-devel
<dschuermann>
yeah, that's expected
<dschuermann>
that's why I wrote both :P
<alyssa>
even on top of the shrink MR, the vec series is still a loss
<alyssa>
will need to pick apart what's happening
<dschuermann>
yes :(
<alyssa>
okay, here is the shader that's hurt hardest on instr count
<dschuermann>
might also want to do the reverse order: first apply 13080 and see how it changes with shrink_vectors
<alyssa>
(19 instr to 33 instr)
mszyprow has quit [Ping timeout: 480 seconds]
<alyssa>
okay, with that fixed, results are much less obnoxious
<alyssa>
`
<alyssa>
total cycles in shared programs: 199852.04 -> 199832.04 (-0.01%)
<alyssa>
cycles in affected programs: 1041.75 -> 1021.75 (-1.92%)
yogesh_mohan has quit [Ping timeout: 480 seconds]
<Venemo>
alyssa: who should I ping about it on this channel?
<alyssa>
dunno
robher has quit [Read error: No route to host]
benettig has quit [Read error: No route to host]
robher has joined #dri-devel
pendingchaos has quit [Read error: No route to host]
benettig has joined #dri-devel
pendingchaos has joined #dri-devel
<danvet>
marex, it's a bit ad-hoc, but what we essentially do in i915 is adjust the adjusted_mode to have the exact right frequency
<danvet>
if you need to change the mode
<danvet>
otherwise maybe it would make sense to expose this as a proper clock source, for which you can then request stuff?
<danvet>
clock subsystem isn't atomic yet, but might work
<marex>
danvet: uh ... wait a minute
<marex>
it's not mode, it's clock between two bridges
<danvet>
also pinchartl probably wants to chime in
<marex>
I am sure pinchartl is busy, so maybe we'll hear from him next month :)
<danvet>
marex, so a clock entirely unrelated to the mode, except it needs to be the right clock so that the dsi bridge can process the mode correctly?
<marex>
danvet: not entirely ... look at this pipeline model for example (hold on, ascii art coming)
<marex>
STM32MP1 ... LTDC <--- DPI at random pixel clock ---> DSI serializer <--- DSI @ clock rate required by the bridge to the right of here ---> TC358767 <--- DPI @ pixel clock required by the panel and generated by the bridge left of here ---> simple DPI panel
<marex>
so that TC358767 driver must somehow say "hey DSI host, I need these clock and no other on the DSI HS clock lane"
<marex>
and I wonder whether atomic_get_input_bus_fmts-alike callback might be the right one maybe ?
<marex>
since that's what's used to negotiate pixel format between two bridges ... and here we need to negotiate not pixel format, but clock frequency, between two neighboring bridges
<danvet>
hm once we had the idea of passing an entire state between each bridge
<danvet>
more callback sounds a bit backwards for this, because there will be eventually an epic pile of them
<marex>
danvet: maybe we need atomic_get_input_bus_state then ? ( https://xkcd.com/927/ comes to mind )
<marex>
that should be future-proof ... and eventually the atomic_get_input_bus_fmts could be wrapped into it
mattrope has joined #dri-devel
<danvet>
marex, not get functions, but instead you allocate a full state from each bridge
<danvet>
and fill them out as you pass
<danvet>
and yeah maybe compat code so that bridge state for get_input_bus_fmts is automatically filled into a default bridge state
<alyssa>
that comment doesn't fit on my screen i'm scared
<jekstrand>
There's a reason only cwabbott and myself are allowed to non-trivially touch nir_algebraic.py. :D
<jekstrand>
Maybe "allowed" isn't quite the right word...
<jekstrand>
How about "are likely to survive non-trivially touching..."
rasterman has quit [Quit: Gettin' stinky!]
cafuffu has quit [Ping timeout: 480 seconds]
<jekstrand>
That file is the epitomy of "contain the insanity". We've trapped Cthulhu inside Pandora's box and made it work for us.
<alyssa>
Oof
<jekstrand>
Incidentally, "Trapping Cthulu in Pandora's box" sounds like a great blog post title. :D
<alyssa>
I guess I want a bcsel(inot(b), x, y) -> bcsel(b, y, x) pass in my backend, speaking of
<alyssa>
though maybe if I lower enough in NIR, early enough, I can reuse NIR's
benettig has quit [Ping timeout: 480 seconds]
benettig has joined #dri-devel
<cwabbott>
I think nir_algebraic really is like a little compiler in the compiler
<jekstrand>
alyssa: Or just get yourself some negative predicates in hardware like Intel has. :P
<alyssa>
jekstrand: Hmm :D
<cwabbott>
it's got a grammar, type-checking, fancy code generation
<alyssa>
truth
<ccr>
"if you gaze into the abyss of nir_algebraic.py long enough, the abyss of nir_algebraic.py also gazes into you" ?
<alyssa>
and, uh, an optimizer ;-0
<cwabbott>
i guess the automaton does kinda count as an optimizer
<jekstrand>
It's a pretty serious code transform at least.
<cwabbott>
yo, I heard you like compilers...
<alyssa>
valhall: MUX executes on SFU when CSEL executes on CVT, despite MUX being ~a subset of CSEL's functionality, and SFU being 4x slower than CVT
<jekstrand>
So why use MUX at all?
<alyssa>
that's what I'd like to know.
<alyssa>
on Bifrost, they're the same perf and it's easier to schedule MUX
<alyssa>
given instr selection is shared between bifrost/valhall but they have different schedulers, I guess isel will always produce MUX and then that'll lower to CSEL in a Valhall-only late pass
<cwabbott>
wait, I thought MUX was the bitwise select thingy?
<alyssa>
cwabbott: that's MUX.bit
<alyssa>
there's also MUX.int_zero, MUX.fp_zero, and MUX.neg
<cwabbott>
oh, I didn't know there was other MUX
<cwabbott>
the joys of reverse-engineering an instruction set
<alyssa>
which act like CSEL, with (x != 0), (x != 0.0), and (x < 0) as the conditions respectively
lemonzest has joined #dri-devel
<cwabbott>
there was an implementation of copysign() in one of the special ops that used MUX.bit that was kinda cute
<alyssa>
heh, nice
<cwabbott>
even though their actual copysign() was worse :(
<alyssa>
the only cute use of it in Mesa is packing the cubemap descriptor
<alyssa>
MUX.bit with a constant mask is a lot cheaper than the equivalent pile of bitwise ops
<cwabbott>
well, if you copied from my descriptions of the special ops then you're using it for one of them... unless it was atan?
<pinchartl>
marex: I think adding the clock rate and other bus parameters (polarities are the first ones that come to mind) to the bridge state is a good idea
<pinchartl>
so that would go to drm_bus_cfg I suppos
<pinchartl>
e
<pinchartl>
but then, the question is how to negotiate it
<alyssa>
could've been atan, that's lowered in glsl ir before I can do it faster :-p
<pinchartl>
I'd rather make the existing negotiation operations more generic to cover clocks, instead of adding other callbacks
<pinchartl>
but I don't know how we could make this negotiation generic to be honest
<cwabbott>
bring back hardware-accelerated atan!
<pinchartl>
in V4L2 we have the same issue, but we're cheating a bit in the sense that we push the problem to userspace
<pinchartl>
solved :-)
ahajda_ has quit []
<pinchartl>
(at least for formats and modes, not for polarities or clock rates)
<marex>
pinchartl: I was just pondering about that
<pinchartl>
so I think what we need here is a good design to negotiate/propagate parameters on a pipeline
<marex>
pinchartl: if atomic_get_input_bus_fmts would return not just a list of pixel formats, but rather a list of supported ... something ... that might be it ?
<pinchartl>
it's not an easy problem, and if we try to cover 110% of all theoretical use cases it will likely become messy, so the difficulty will be to find a good middleground
<marex>
like a list of structures ... { pixel_format, clock_range {min, max} } ?
<marex>
then such structure could be expanded when we need to add more stuff ?
<pinchartl>
possibly. I don't know I'm afraid
<pinchartl>
one of the issues is that the current mechanism for format negotiation kind of tries to search the entire problem space
<marex>
I suspect we have to do that
<pinchartl>
it may work for formats, but if we add other parameters to the mix, it will become a mess
<pinchartl>
but I haven't researched how this can be improved
<marex>
take e.g. the DSI , for pixel format with fewer bytes per pixel, you can use slower bus clock
<pinchartl>
one very important requirement here is to define the negotiation operations very clearly (this includes documentation), otherwise we'll have different bridges that have different ideas of what needs to be done, tested separately on different platforms, but they won't interoperate correctly if they are mixed in a new platform
<pinchartl>
so whatever we end up doing, documentation has to be cristal clear on exactly what a bridge driver must implement
<mripard>
it would be useful to also filter out modes that can't be reached by one component in the chain, we have a few ad-hoc solutions that could benefit from this too
<marex>
I think that's exactly what would happen if we pass in and pass out a list of { pixel_format, clock_range {min, max} }, because then every bridge would make that list smaller, right ?
<marex>
in the worst case, the bridge would pass the list through as-is
<marex>
pinchartl: returning the list of (extended) drm_bus_cfg looks good
<mripard>
it depends on how it's implemented :)
<mripard>
and it also depends on the mode
<marex>
mripard: it will be perfect in V1 patch :)
<marex>
mripard: the DSI bus mode ?
<mripard>
which pixel format and which clock range you support
<marex>
mripard: right, that we can pass around via drm_bus_cfg list ...
<marex>
mripard: there is another issue -- the DSI itself can operate in multiple modes
<marex>
burst mode being the most efficient, and with slowest DSI HS clock AFAICT
<mripard>
my point was that it's not limited to DSI :)
<marex>
mripard: right, so with DPI, that's easy, that's only pixel clock pretty much
<mripard>
you could use that information if you have an RGB encoder + something like an HDMI bridge
<marex>
LVDS, similar thing
<marex>
(e)DP could be a bit iffy ?
<mripard>
there's no chance that your RGB interface can feed that 4k/60Hz monitor
<marex>
mripard: then that interface will have to reject all the drm_bus_cfg coming from the last bridge (the one connected to it) and it's all over ?
maxzor has quit [Ping timeout: 480 seconds]
<mripard>
marex: to some extent, yeah. But you have the same issue at mode_valid
<mripard>
and you don't have drm_bus_cfg there
<mripard>
even with your use case, if your last panel requires a mode that is outside of what your DSI device wants to have, you want to filter it out
<mripard>
otherwise, chances are that userspace will just try to use it by default, and won't work because it's rejected by atomic_check
<marex>
mripard: isn't the mode_valid issue a bit separate ?
<marex>
I kind-of understand it , not entirely , so pardon my ignorance here
<mripard>
kind-of, but kind-of not too :)
<marex>
mripard: isn't the mode_valid going to be superseded by something ?
<mripard>
your initial issue is that you wanted to force a clock for a given device in the bridge chain
<marex>
mripard: depending on the device, clock or range of clock per pixel format
<mripard>
so you also have to handle what happens when you just can't use that clock, for whatever reason
<marex>
well in that case, you just cant bring the pipeline up ?
<mripard>
just returning -EINVAL at atomic_check is weird
<mripard>
because you kind of have the expectation that any mode listed by a connector work, and especially the first one which is supposed to be the preferred mode
<mripard>
a preferred mode that flat out doesn't work when you use it would be *very* weird :)
<mripard>
so you want to filter it out for the userspace, and that's mode_valid's job
<mripard>
which, afaik, isn't going away
<marex>
ah
<mripard>
I'm not sure it should be tied to the atomic state here, I think we'd want it to be usable without a state
<mripard>
(but would definitely use it in some part of atomic_check too)
<marex>
mripard: all right, lemme prepare an RFC patch and then I'll Cc you to help review it ?
* marex
expects discussion similar to DSIM discussions :-)
MajorBiscuit has quit [Ping timeout: 480 seconds]
<mripard>
sure
krushia_ has quit []
krushia_ has joined #dri-devel
krushia_ has quit []
cafuffu has joined #dri-devel
* alyssa
experiments with pass order
rgallaispou has quit [Ping timeout: 480 seconds]
devilhorns has quit []
<alyssa>
hrm. I can't lower b2f -> bcsel in a normal algebraic pass, because that fights with the bcsel -> b2f opt
<alyssa>
but if I lower it late, I miss out on the b2f(inot(x)) pattern
<alyssa>
maybe the real answer is to lower it late and special case the inot patterns...
<alyssa>
It feels dirty, but it does the tirck.
<alyssa>
trick
gawin has quit [Ping timeout: 480 seconds]
cheako has quit [Quit: Connection closed for inactivity]
ngcortes has joined #dri-devel
maxzor has joined #dri-devel
maxzor has quit [Remote host closed the connection]
maxzor has joined #dri-devel
mbrost_ has joined #dri-devel
mbrost__ has joined #dri-devel
mbrost_ has quit [Read error: Connection reset by peer]
ramaling has quit [Ping timeout: 480 seconds]
mbrost__ has quit [Read error: Connection reset by peer]
ybogdano has quit [Ping timeout: 480 seconds]
pzanoni has quit [Ping timeout: 480 seconds]
mbrost has quit [Ping timeout: 480 seconds]
ngcortes has quit [Read error: Connection reset by peer]
mattrope has quit [Ping timeout: 480 seconds]
cafuffu has quit [Read error: No route to host]
cafuffu has joined #dri-devel
mattrope has joined #dri-devel
maxzor_ has joined #dri-devel
ngcortes has joined #dri-devel
mbrost has joined #dri-devel
maxzor_ has quit []
ybogdano has joined #dri-devel
fxkamd has quit []
ybogdano has quit [Ping timeout: 480 seconds]
<marex>
sigh ... Lontium ... why oh why do you not release any useful datasheets like any sane DSI bridge vendor would :-C
* marex
shakes fist
mclasen has quit [Ping timeout: 480 seconds]
benettig has quit [Ping timeout: 480 seconds]
ybogdano has joined #dri-devel
benettig has joined #dri-devel
karolherbst has quit [Read error: Connection reset by peer]
karolherbst has joined #dri-devel
cafuffu has quit [Ping timeout: 480 seconds]
pzanoni has joined #dri-devel
ramaling has joined #dri-devel
ybogdano has quit [Ping timeout: 480 seconds]
heat has joined #dri-devel
cafuffu has joined #dri-devel
ngcortes has quit [Ping timeout: 480 seconds]
ybogdano has joined #dri-devel
ngcortes has joined #dri-devel
ngcortes has quit [Quit: Leaving]
ngcortes has joined #dri-devel
Molnija has joined #dri-devel
Molnija has left #dri-devel [#dri-devel]
Lightning has joined #dri-devel
mclasen has joined #dri-devel
fxkamd has joined #dri-devel
heat_ has joined #dri-devel
heat has quit [Read error: No route to host]
ngcortes has quit [Ping timeout: 480 seconds]
jfalempe has quit []
<graphitemaster>
Isn't it nice when your enjoying your quiet Friday evening with a shot of Hennessy and nothing is on fire, bugs and issues cease to exist, if there's an emergency nobody is going to notice. Graphics just takes a back seat. It's poetic in a way. We spend all this effort on turning pixels a different color other than black, and the weekend I can get blasted so my real life pixels go black.
<graphitemaster>
Full circle stuff
Duke`` has quit [Ping timeout: 480 seconds]
mvlad has quit [Remote host closed the connection]
<alyssa>
graphitemaster: are you ok?
<graphitemaster>
alyssa, what if drivers are just ad hoc hang over cures for gpus that drank a little too much
danvet has quit [Ping timeout: 480 seconds]
cafuffu has quit [Ping timeout: 480 seconds]
mhenning has joined #dri-devel
gouchi has quit [Remote host closed the connection]