<airlied>
daniels: ^ is who I think we are waiting on
danvet has joined #dri-devel
thellstrom has joined #dri-devel
f11f13 has joined #dri-devel
dllud_ has joined #dri-devel
dllud has quit [Read error: Connection reset by peer]
dllud has joined #dri-devel
dllud_ has quit [Read error: Connection reset by peer]
dllud_ has joined #dri-devel
dllud has quit [Read error: Connection reset by peer]
shadeslayer[m] has quit []
shadeslayer[m] has joined #dri-devel
pnowack has joined #dri-devel
kmn has joined #dri-devel
jkrzyszt has joined #dri-devel
jkrzyszt has quit [Remote host closed the connection]
jkrzyszt has joined #dri-devel
aravind has quit [Read error: Connection reset by peer]
<dj-death>
airlied: thanks :)
camus has quit [Remote host closed the connection]
camus has joined #dri-devel
thellstrom has quit [Quit: thellstrom]
thellstrom has joined #dri-devel
dreda has quit [Ping timeout: 480 seconds]
rasterman has joined #dri-devel
<MrCooper>
mareko: aren't they just different names for the XID?
urja has quit [Ping timeout: 480 seconds]
tolszak has joined #dri-devel
tursulin has joined #dri-devel
thellstrom has quit [Ping timeout: 480 seconds]
pcercuei has joined #dri-devel
milkylainen has joined #dri-devel
<milkylainen>
Does the kmsro driver create any lib target files? I've built mesa for 21.2.3 for my embedded target, selected kmsro... but there seems to be no difference in either compiled files or created .so files?
<milkylainen>
No build failures or nothing.
JohnnyonFlame has quit [Ping timeout: 480 seconds]
gawin has joined #dri-devel
<MrCooper>
it'll be included in *_dri.so or maybe lib*_mesa.so.0, not in its own .so
<milkylainen>
MrCooper: Ok thanks. But shouldn't the number of compiled files change? My build has 1620 something target objects with or without kmsro.
<MrCooper>
I suppose so; actually, the toplevel meson.build looks like kmsro is automatically selected for the v3d/vc4/etnaviv/panfrost/lima/freedreno drivers, cannot be explicitly selected
<milkylainen>
Aha.
<milkylainen>
Hrm. I can select kmsro?
<milkylainen>
Gallium drivers: kmsro svga virgl r600 nouveau swrast
<milkylainen>
Gallium drivers: virgl r600 nouveau swrast svga
<milkylainen>
Doesn't complain in either case.
cengiz_io__ has quit []
cengiz_io has joined #dri-devel
pendingchaos_ is now known as pendingchaos
tobiasjakobi has joined #dri-devel
tobiasjakobi has quit [Remote host closed the connection]
dreda has joined #dri-devel
<daniels>
airlied: not me, looks like a system issue and that machine is run by the GStreamer people, but I'll forward the poke
shankaru has joined #dri-devel
<daniels>
ah, they've already been poked
shankaru has left #dri-devel [#dri-devel]
shankaru1 has joined #dri-devel
milkylainen has quit [Quit: Ping timeout (120 seconds)]
<daniels>
if it's blocking then anyone can do this, no need to wait for me
<dj-death>
yeah never quite sure :)
Danct12 has joined #dri-devel
<daniels>
if it's broken, kill it
itoral has quit [Remote host closed the connection]
nchery has joined #dri-devel
jfalempe has joined #dri-devel
zmike_ is now known as zmike
<mareko>
MrCooper: I think you're asking the wrong guy, I don't know what that term means
<pq>
mareko, XID is an integer id that in X11 protocol refers to some kind of an object, like a window. The C type Window is just an alias to the type XID.
<danvet>
so that's not the bugfix we need to pick up then?
<danvet>
or is gregkh wrong?
* danvet
confused
<imirkin>
jasuarez: you're checking for a desktop GL 4.2 context. so in an ES context, a driver supporting format-less stores will still generate the variants.
<imirkin>
jasuarez: imho the best thing to do is to add a cap and use that new cap to advertise ARB_shader_image_load_store
<tzimmermann>
what i meant was that the current drm-misc-next-fixes is based on drm-misc-next-2021-10-14. and that tag does not require the namespace fix
alyssa has left #dri-devel [#dri-devel]
<tzimmermann>
danvet, do you have a link to greg's mail?
f11f13 has quit []
f11f12 has joined #dri-devel
<danvet>
5c904c66ed4e86c31ac7c033b64274cebed04e0e <- char-misc pull explains it
<tzimmermann>
but it was only required because linux-next pulls drm-misc-next or drm-tip
<danvet>
tzimmermann, hm we should be pushing drm-misc-next-fixes to linux-next during merge window
<tzimmermann>
danvet, i'll checkout linus' tree tomorrow and do an allmodconfig build for arm64
<tzimmermann>
to see what fails
<tzimmermann>
but how would drm-misc-next-fixes helped to avoid the confusion?
zackr has joined #dri-devel
<danvet>
tzimmermann, so during merge window dim should only push drm-misc-next-fixes
<danvet>
and not drm-misc-next to linux-next
<danvet>
so that people don't freak out about breakage during the merge window in linux-next due to stuff that's for the next merge window
<tzimmermann>
danvet, i think this started before the merge window opened. we had that gem-patch in drm-misc-next. stephen fixed the issue for linux-next. then the merge window opened. then we pushed the real fix into drm-misc-next. linux-next was now stuck with the intermediate fix
<tzimmermann>
just my theory...
sdutt has joined #dri-devel
<tzimmermann>
i added the real fix on friday the 29th. the merge window opened that weekend
<tzimmermann>
why the linux-next fix got picked up into a PR for upstream; i don't know
<danvet>
tzimmermann, yeah maybe it's just bad timing
<danvet>
and mripard being a bit too late with opening drm-misc-next-fixes, that should usually happen after -rc6
<danvet>
so 1-2 weeks before merge window
<danvet>
exactly to avoid such last minute flapping and confusion
fxkamd has quit []
<emersion>
danvet: "drm/drm_plane.h: fix a typo: not -> note" was already merged
<emersion>
but in drm-misc-next i thinkl
alyssa has left #dri-devel [#dri-devel]
<emersion>
same patch from different person
<danvet>
emersion, yeah just noticed the mail from tzimmermann
<danvet>
for typo fixes I kinda don't care that much, but when people send them in a lot I put it into -fixes to stop it :-)
fxkamd has joined #dri-devel
kazlaus has joined #dri-devel
X-Scale has joined #dri-devel
JohnnyonFlame has joined #dri-devel
urja has joined #dri-devel
X-Scale` has quit [Ping timeout: 480 seconds]
<kazlaus>
danvet: to continue off the discussion off the mailing list, is the issue with the -EBUSY just that it's the CRTC object itself that's contested?
<danvet>
kazlaus, yeah
<kazlaus>
even if we synchronize DRM private objects and stall out on those that's fine?
<kazlaus>
it seems like you're still going to get judder
<danvet>
yeah, but hopefully minimal amounts since you thought about what exact global state to sync again
<danvet>
and track its update with a dedicated drm_crtc_commit (or well drm_hw_commit)
<danvet>
like ... hw sucks
<kazlaus>
I guess in some sense you can assume that a page flip on a secondary display will still pass
<danvet>
yeah with this approach a pure flip on the others crtc should go through in parallel
<danvet>
so it should be better than "grab all crtc"
<danvet>
also the real catch is the uapi visibility of the events and ebusy
<danvet>
we already cheat in other areas, e.g. for psr self-refresh the wakeup might be slower than "will hit next frame"
<jasuarez>
imirkin: I thought about creating the cap, but there are several other extensions that seems to require this shader_image_load_store, including of course the ES3.1, and I'm not sure if they require to have a complete implementation or not
<danvet>
kazlaus, also for private state struct it might be a good idea to make the drm_crtc_commit opt-in
<kazlaus>
so the solution for my problem is probably just adding actual synchronization to DRM private objects... and hope that doesn't break other drivers that use that
<kazlaus>
yeah
<danvet>
i.e. only create one on explicit driver request
<danvet>
and then just sync against the most recent one if there is any
<kazlaus>
there aren't that many users but i think some people assume that it's not synchronized
<danvet>
since often it would be redundant, but also very often changes in limits don't actually require a reallocation of resources
<danvet>
so would be silly to block when nothing actually changed
<danvet>
kazlaus, the existing ones all have their own sync, if needed
<danvet>
but e.g. the dp mst stuff is already protected by connector tracking
<danvet>
so really doesn't need any additional tracking
<danvet>
but for some other drivers it might help
<kazlaus>
like just extending it in the driver private state? I guess that works as a short term solution
<danvet>
kazlaus, like vc4 maybe could use that "make a drm_crtc_commit for this state now" helper
<danvet>
not sure how pinchart1 solved this
<imirkin>
jasuarez: i don't see the comment, weirdly. ES 3.1 actually does *not* depend on GL_ARB_shader_image_load_store. but ES 3.2 does.
<danvet>
kazlaus, nah I think that's the long term fix
<imirkin>
jasuarez: but it's all made-up dependencies, and we can have it depend on whatever it wants
<danvet>
a) add drm_crtc_commit pointer to drm priv state struct
<imirkin>
s/it wants/we want/
<danvet>
b) sync against that if it's there, like for all the others we have
gawin has quit [Ping timeout: 480 seconds]
<danvet>
c) add helper to create one (maybe with a state flag boolean so that setup_commit does it for you at the right time)
<imirkin>
jasuarez: you could make the ext depend on the new cap, and then make ES 3.2 depend on the current condition that enables the ext (iirc image support in FS)
<danvet>
kazlaus, if that works for both vc4 and amdgpu then I think we can call it solid enough and ship it
<danvet>
kazlaus, also if you convert vc4 I can offload review to mripard :-P
macromorgan has quit [Quit: Leaving]
<kazlaus>
I guess I can take a look at it
<kazlaus>
I really want to get rid of our hack of stalling in atomic check
<imirkin>
it wasn't there a minute ago. i swear. even clicking on your link with the note reference didn't find it
<jasuarez>
for instance, we enable compute_shader if we support that extension, but I don't know if we need to fully support the extension, of if it's fine with not having formatless store
<jasuarez>
and checking compute_shader extension, I don't see any hard dependency on that one
<imirkin>
jasuarez: it's desktop GL, so yes, required.
<imirkin>
jasuarez: you'd have to double-check the AEP ext details, since they sneakily add some requirements in the EXT spec itself, not just the 30 exts it depends on
mbrost has joined #dri-devel
<imirkin>
but i doubt they'd add something like that. they mostly mess with required minimums iirc
<jasuarez>
specs are a mess, tbh
<jasuarez>
i need to leave now, i'll check tomorrow
<imirkin>
yes. much better were the old days "this ext string means what I say it means!"
<jasuarez>
thanks for the tips!
<imirkin>
[and that's how we end up with GL_ATI_shadow_texture_lod or whatever, which is spec-less but games depend on it]
<emersion>
fyi: i'm planning on doing a new libdrm release
<imirkin>
jasuarez: btw, a bunch of people here have a near-encyclopaedic knowledge of specs, so feel free to ask here in case people can save you some time
<jenatali>
Ugh my threaded context series introduces a flake that I can't repro :(
<zmike>
jenatali: I assume you've tried simulating extreme cpu load?
<jenatali>
Not yet
<zmike>
otherwise prob just a buffer rebind problem
<zmike>
or at least that's where mine came from
<jenatali>
Nah I fixed those, but they weren't flaky
<jenatali>
This is xfb reporting an extra primitive being drawn
<zmike>
xfb rebind problem maybe?
<jenatali>
Hm... yeah maybe
<zmike>
I had one of those once
<jenatali>
Don't get why it'd be flaky though
<zmike>
gpu cache?
<jenatali>
Unlikely. Repros on software
<jenatali>
I'll figure it out eventually
<ajax>
mareko: you cast them. they're just integer handles. the xlib type is an alias for long and the xcb type is an alias for uint32_t.
<ajax>
and they're 32 bit handles (29, don't ask) so
macromorgan has joined #dri-devel
jstultz_ has quit []
jstultz has joined #dri-devel
idr has joined #dri-devel
* zmike
starts fingerpainting in mesa/main
<imirkin>
ajax: but 30 on 32-bit systems? :)
tolszak has quit [Ping timeout: 480 seconds]
ybogdano has joined #dri-devel
tolszak has joined #dri-devel
Peste_Bubonica has joined #dri-devel
gouchi has joined #dri-devel
jewins has joined #dri-devel
ybogdano has quit [Ping timeout: 480 seconds]
fxkamd has quit []
fxkamd has joined #dri-devel
ybogdano has joined #dri-devel
gawin has joined #dri-devel
kazlaus has quit [Quit: Leaving]
tzimmermann has quit [Quit: Leaving]
lemonzest has quit [Quit: WeeChat 3.3]
jkrzyszt has quit [Ping timeout: 480 seconds]
dviola has quit [Remote host closed the connection]
dviola has joined #dri-devel
<jenatali>
zmike: Found it. Uninitialized stack memory when constructing primconvert_config
<jenatali>
No idea why the tc change triggered it to be more flaky, it should've always been flaky
<zmike>
jenatali: memory problems. how dastardly.
<jenatali>
Yep
krh_ is now known as krh
f11f12 has quit [Remote host closed the connection]
f11f12 has joined #dri-devel
<robclark>
danvet: looking at moving to do submit/job retire/recovery the drm/sched way.. since it looks like it would let me delete a bunch of code.. but I can't convince myself that drm_sched_job_timedout() actually works properly.. ie. what is preventing the thing at the head of sched->pending_list from being a job that successfully completed but drm_sched_main() just hasn't gotten around to handling it yet? What am I missing?
<robclark>
(and why even bother handling timedout_job() from wq instead of drm_sched_job_timedout() itself.. which would solve the issue)
f11f12 has quit [Remote host closed the connection]
f11f12 has joined #dri-devel
gouchi has quit [Remote host closed the connection]
Daanct12 has joined #dri-devel
Duke`` has quit [Ping timeout: 480 seconds]
Danct12 has quit [Ping timeout: 480 seconds]
gawin has quit [Ping timeout: 480 seconds]
Peste_Bubonica has quit [Quit: Leaving]
pcercuei has quit [Quit: dodo]
minecrell has quit [Quit: Ping timeout (120 seconds)]
minecrell has joined #dri-devel
gawin has joined #dri-devel
<robclark>
danvet: looks like "drm/sched: serialize job_timeout and scheduler" would fix this.. does seem like it would be simpler to handle timedout_job() from drm_sched_main() instead, but that would somewhat change the driver api for timeout/recovery.. I guess I'll stick with our existing timeout/recovery for now and revisit when the dust settles (and maybe when I don't have to care about backporting to v5.4 without breaking amdgpu on
<robclark>
that kernel)
<danvet>
robclark, so a bit late maybe chat tomorrow
<danvet>
but in general I have "review barriers and ordering around drm/sched" on my todo list since a few months :-)
<robclark>
I'll reply on list to that thread
<danvet>
but roughly the idea is a) you stop all affected scheduler threads (which you can escalate as you go if you e.g. can try preempt on the engine first and then reset across all engines)
<robclark>
might be the more timezone-compatible way to work ;-)
<danvet>
b) no more races
<danvet>
but also it's very tricky in details
<danvet>
robclark, also yes amdgpu got broken a few times and/or they have funny requirements
<danvet>
or at least their hpc group had a bit thread this summer about something they wanted to do that made no sense at all
<danvet>
robclark, so reason for separate timeout workqueu is if you have reset spawning engines, so spawning multiple schedulers
<danvet>
where you need to stop them all
<danvet>
that got recently fixed by bbrezillon, by allowing you to pass a single-threaded wq to the scheduler
<robclark>
yeah, I got that much by digging thru git history
<danvet>
so that you can run all the timeouts on one wq to avoid races
<danvet>
but it also means we can't run the timeout in the scheduler thread
<robclark>
right.. but there is still a way to handle both, I think
<danvet>
and really all chips I know of with more than one engine have some across-engines reset (sometimes it's the only one)
<danvet>
so we really need to support that
nchery has quit [Quit: Leaving]
<danvet>
robclark, yeah it's the "stop affected sched kthread" approach
<danvet>
since reset is very exceptional we can push all the complexity in there
<robclark>
or if sched->timeout_wq != system_wq, then queue to timeout_wq and block until it returns
<robclark>
(from sched thread)
ybogdano has quit [Ping timeout: 480 seconds]
mclasen has quit []
mclasen has joined #dri-devel
<danvet>
hm maybe I'm also too tired to get what exactly you're pondering
<airlied>
one of the a630 seems to be having network problems
<robclark>
hmm, I thought anholt hooked something up to detect that error and restart
alatiera12 is now known as alatiera
alyssa has joined #dri-devel
<alyssa>
...Why is LD_PRELOAD'ing an empty library causing this app to crash?
<alyssa>
but only this one
<alyssa>
....when I have multiple TEST(..) it works but with only one it does not
<alyssa>
I, uh, Android why must you be difficult
<airlied>
robclark: needs hooking up more then :-P
<robclark>
alyssa: is LD_PRELOAD already non-null? I've seen some android devices that use systemwide preload for *something*
<robclark>
airlied: oh, I think the thing that it is already looking for is actually network errors on tftpboot.. rather than later when nfsroot disappears
<alyssa>
robclark: seems to be empty.
<alyssa>
also, that's horrifying.
<alyssa>
.........Why does the Arm driver emit 350 lines of assembly just to setup instancing
<airlied>
alyssa: because it's more complicated than you think? :-P
<imirkin>
alyssa: because it was optimized from 1000 lines? :)
<alyssa>
terrifying
<alyssa>
Is there any precedent for static decompiling GPU ISAs?
<alyssa>
If not, hey daniels want a collabora talk at Black Hat next year? :-P
<imirkin>
for nouveau, we definitely fuzz the nvdisasm tool ;)
<alyssa>
imirkin: this is the case of "I know the ISA, but the driver emits a mystery shader that I want to understand"
<alyssa>
For 10s of lines, I would manually convert to C code
<imirkin>
oh
<imirkin>
like ... that tool whose name i always forget
<airlied>
think how would I do instancing, then how would I do it if I worked at ARM
<alyssa>
ghidra?
<imirkin>
which basically converts asm to BB's
<imirkin>
yes, that's the one
<alyssa>
airlied: you would add a 3 line patch to llvmpipe to support instancing like a normal person,
<airlied>
then add some org chart layers, and write that should end up close enough
<imirkin>
actually there's another one too, but same idea
<alyssa>
unless you worked Arm in which case you would add a 500 line patch in GLSL and use that instead
<imirkin>
adreno a3xx instancing only supports drawing up to 256 instances in one go, so having odd instance dividers causes much oddity
<alyssa>
Instancing was reasonableish on older Mali
<alyssa>
I'm not sure why they would make it worse, but..
<imirkin>
(the current solution taken by freedreno is "ignore any draws that ask for > 256", which is probably suboptimal)
<alyssa>
(Someone at Arm) hold my beer
<imirkin>
any time there's any sort of oddness, the blob driver just gives up and draws one-at-a-time
<imirkin>
but you can do better with math :)
<alyssa>
am I going to do something stupid? you bet!
danvet has quit [Ping timeout: 480 seconds]
<anholt>
robclark, airlied: that's a new error signature