ChanServ changed the topic of #dri-devel to: <ajax> nothing involved with X should ever be unable to find a bar
glennk has quit [Ping timeout: 480 seconds]
<dominoeffect>
HdkR: in the paradigm i represented there is no such latent concept as counting bits as in binary code. it's that you did not pay enough attention. 114+84+270 aka 114+354 is 468 ripping it out into finer granules is as told 232+118+118, now you technically count bits with some ways referring back orforth from 118 to 117 or 119 where on duplicates other elements are at 114 such line
<dominoeffect>
233+118+118−119−119−119=112 so 114+114-112-114=2, as those banks are assymmetric for multivalue/multicell access or not proportional, our first quantum computing arithmetic is multibank/multivalue assymmetric multiply, or you are in a loop or iteration and can multiply with ISA instr too, so 2*118=236, so counting bits and inverse out bits is just ridiculously fast and easy. You are
<dominoeffect>
fucking nonsense guys i am not interested to deal with you, such person as Lynne and her heroics do not exist, the video decoder was updated by AI, and given out from huawei research labs by my private lab and was called DLVC deep learning based video decoder formulation through the screen scraping of framebuffer and deriving the needed code some semiotic experts call this as inferring
<dominoeffect>
(google for modulus ponens and wikipedia) i did the same for opencl with boyi so those stacks came from china and south-korea , my code is way stronger than theirs, but perhaps too strong for general public, I break RSA next year, i have list of abusers to kill elsewhere, it seems you are not defined as per logic that gave you senses as for other human beings like me Mart Martin. Not
<dominoeffect>
joss as a soon dead man abuser called me, I gave him opportunity after he had injured me for life, that he does couple of years in prison where we add a buddy to his cell, he gets anal every day until the nose bleeds every single day for attacking me uncouncious from behind the back and implanting a chip to my neck or if he does not do that, we torture and kill him. Once again I am no
<dominoeffect>
longer interested to deal with you.
yshui_ has quit [Ping timeout: 480 seconds]
<HdkR>
oh, what fun timing
jernej- has joined #dri-devel
Jeremy_Rand_Talos__ has joined #dri-devel
jernej has quit [Read error: Connection reset by peer]
Jeremy_Rand_Talos_ has quit [Read error: Connection reset by peer]
iive has quit [Quit: They came for me...]
dominoeffect has quit [Remote host closed the connection]
epoch101 has quit []
guludo has quit [Ping timeout: 480 seconds]
The_Company has joined #dri-devel
Company has quit [Ping timeout: 480 seconds]
feaneron has quit [Ping timeout: 480 seconds]
davispuh has quit [Ping timeout: 480 seconds]
karolherbst has quit [Read error: Connection reset by peer]
karolherbst has joined #dri-devel
Low_Orbit_Michelson-Morley has joined #dri-devel
oneforall2 has quit [Ping timeout: 480 seconds]
epoch101 has joined #dri-devel
epoch101 has quit []
bolson has quit [Ping timeout: 480 seconds]
Daanct12 has joined #dri-devel
sally has quit []
sally has joined #dri-devel
Jeremy_Rand_Talos__ has quit [Remote host closed the connection]
Jeremy_Rand_Talos__ has joined #dri-devel
oneforall2 has joined #dri-devel
nerdopolis has quit [Ping timeout: 480 seconds]
KitsuWhooa has quit [Quit: Unable to handle kernel NULL pointer dereference at null]
<MrCooper>
chema: being discussed on #freedesktop (infra issues in general)
<mlankhorst>
chema: I have issues. :-)
tursulin_ is now known as tursulin
* ccr
has coffee.
vyivel has quit [Ping timeout: 480 seconds]
vyivel has joined #dri-devel
ao2_collabora has joined #dri-devel
<MrCooper>
should be better now
Fya has joined #dri-devel
Fya has quit [Remote host closed the connection]
Sid127 has quit [Remote host closed the connection]
caitcatdev has quit [Remote host closed the connection]
Sid127 has joined #dri-devel
caitcatdev has joined #dri-devel
warpme has quit []
haaninjo has joined #dri-devel
vyivel has quit [Ping timeout: 480 seconds]
vyivel has joined #dri-devel
<eric_engestrom>
karolherbst: yes, the branchpoint is planned for tomorrow, as in wednesday (since you asked 11h ago that might have been a different "tomorrow" ^^)
<karolherbst>
yeah I uhm.. noticed too late it was past midnight 🙃
Sid127 has quit [Read error: Connection reset by peer]
caitcatdev has quit [Read error: Connection reset by peer]
Sid127 has joined #dri-devel
linkmauve has left #dri-devel [Error from remote client]
caitcatdev has joined #dri-devel
<eric_engestrom>
if anyone wants to help, one MR is about NIR and the other one X11
rasterman has quit [Remote host closed the connection]
Sid127 has quit [Read error: Connection reset by peer]
caitcatdev has quit [Remote host closed the connection]
caitcatdev has joined #dri-devel
krushia has joined #dri-devel
Sid127 has joined #dri-devel
jkrzyszt_ has joined #dri-devel
jkrzyszt has quit [Ping timeout: 480 seconds]
Sid127 has quit [Read error: Connection reset by peer]
Sid127 has joined #dri-devel
caitcatdev has quit []
tlwoerner_ has joined #dri-devel
caitcatdev has joined #dri-devel
tlwoerner has quit [Ping timeout: 480 seconds]
jkrzyszt has joined #dri-devel
jkrzyszt_ has quit [Ping timeout: 480 seconds]
jkrzyszt_ has joined #dri-devel
linkmauve has joined #dri-devel
jkrzyszt has quit [Ping timeout: 480 seconds]
tlwoerner has joined #dri-devel
tlwoerner_ has quit [Ping timeout: 480 seconds]
apinheiro has joined #dri-devel
krushia has quit [Quit: Konversation germinated!]
jkrzyszt has joined #dri-devel
jkrzyszt_ has quit [Ping timeout: 480 seconds]
<austriancoder>
eric_engestrom: how can I add a MR to a milestone?
jernej| has joined #dri-devel
jernej has joined #dri-devel
<eric_engestrom>
austriancoder: in the right column of the MR, where all the metadata is, you have a "milestone" section; select it there
<austriancoder>
eric_engestrom: nice
jernej| has quit [Read error: Connection reset by peer]
DarkShadow4444 has joined #dri-devel
jernej has joined #dri-devel
jernej- has quit [Ping timeout: 480 seconds]
jernej has quit [Remote host closed the connection]
DarkShadow4444 has quit [Read error: Connection reset by peer]
yshui has quit [Ping timeout: 480 seconds]
jernej has joined #dri-devel
Karyon has quit [Quit: ZNC 1.9.0+deb2build3 - https://znc.in]
Karyon has joined #dri-devel
Karyon has quit []
Karyon has joined #dri-devel
DarkShadow4444 has joined #dri-devel
teebuthot[m] has quit [autokilled: This host violated network policy. Contact support@oftc.net for further information and assistance. (2025-07-15 10:51:38)]
jernej has quit [Remote host closed the connection]
jernej has joined #dri-devel
DarkShadow44 has quit [Ping timeout: 480 seconds]
vyivel has quit [Ping timeout: 480 seconds]
jernej has quit [Remote host closed the connection]
<robclark>
karolherbst: why does flush_events() pipe.flush().wait() (ie. the .wait() part).. this seems to be the same thread launching grids, so this introduces a stall
Mangix has quit [Ping timeout: 480 seconds]
rasterman has quit [Quit: Gettin' stinky!]
leo60228 has quit [Read error: Connection reset by peer]
leo60228 has joined #dri-devel
yshui has joined #dri-devel
Lyude has quit [Read error: Connection reset by peer]
yshui_ has quit [Ping timeout: 480 seconds]
djbw has joined #dri-devel
<karolherbst>
robclark: no good reasons except I need to put the events into the proper state at some point and I'm doing it on the host atm
<karolherbst>
well with cross queue dependencies it's kinda required because applications rely on it
<jenatali>
FWIW I push that work into a thread pool
<robclark>
hmm, you could keep a queue of already flushed but not waited fences and associated events.. then defer the wait until needed (cross queue) and cleanup until signaled?
<karolherbst>
yeah same
<karolherbst>
robclark: I wanted to associate fences with events at some point, it's just a bit annoying, because the application can also register callbacks
<karolherbst>
and they might signal user events in those callbacks
<karolherbst>
without waiting on anything
<karolherbst>
so at some point I do have to know when the stuff is actually completed
<robclark>
sure, you could always wait for pending fences if you get into a corner, but not doing it in the common case would help perf :-)
<karolherbst>
yeah....
<jenatali>
Yeah I've got a thread pool per device that basically serializes all queues down to something like a gallium context. Right now it serially calls flush + wait when it submits work
<jenatali>
I think it's technically against spec though
<karolherbst>
it was worse in the past where I waited after each event :D
<karolherbst>
right...
<karolherbst>
rusticl does the flush + wait after all events sent to the queue were processed (or for other reasons like before waiting on user events)
<karolherbst>
it's not great.. but I don't really know of a lot of better ways of handling this.. well except I could check if nothing can observe the event
<jenatali>
> When a task becomes ready, any other tasks that depend on it that can execute on the same device will also be marked ready. Technically, this is a violation of the CL spec for events, because it means that given task A and task B, where B depends on A, both A and B can be considered 'running' at the same time. The CL spec explicitly says that an event should only be marked running when previous events are 'complete', but this seems like a
<jenatali>
more desireable design than the one imposed by the spec.
<karolherbst>
easy
<karolherbst>
you put them to running and complete after they completed :P
<karolherbst>
the issue is more the callbacks on CL_COMPLETE
<jenatali>
What's the issue there?
<karolherbst>
the application could have added a completion callback that signals user events
yshui has quit [Ping timeout: 480 seconds]
<karolherbst>
so you have to eventually put events into CL_COMPLETE state (and call those callbacks) without the application waiting on anything
urja has quit [Read error: Connection reset by peer]
<karolherbst>
might even just flush + wait on the user event
<jenatali>
Right, hence the worker thread that basically executes in lock-step with the device
urja has joined #dri-devel
<karolherbst>
right
<karolherbst>
that's what I do as well
<karolherbst>
but as robclark points out, that causes stalls
<karolherbst>
if there would be a primitive we could use where the GPU could tell the host it is done with something 🙃
<karolherbst>
anyway.. I think a proper fix would require some gallium changes
<karolherbst>
basically need the GPU to set the event and the host to be notified about it _somehow_
<jenatali>
Oh, right. IIRC I've got 2 threads actually, one which kicks off work and one which watches for progress
<karolherbst>
mhhh
<karolherbst>
like something that just checks every second or so if the status changed?
<karolherbst>
not that gallium has any APIs for that atm anyway
<robclark>
karolherbst: you can wait on a fence from another thread besides the one that is calling pipe_context::whatever()
<jenatali>
No, the one that kicks off work enqueues a fence signal, and then posts a message to the other thread to wait for the signal to complete
<jenatali>
Yeah, that
<robclark>
so you just need a second thread to do the waits and cleanups.. and then sync with that thread for cross-queue or whatever other edge cases
<karolherbst>
mhhh
<karolherbst>
yeah... probably
<karolherbst>
more threads
<karolherbst>
I just wished there would be a better way
<karolherbst>
like drivers have access to a sequence number
<karolherbst>
some drivers do
<karolherbst>
iris has it
<jenatali>
That's still just polling though?
<jenatali>
How is that better?
<karolherbst>
mapped
<karolherbst>
but yeah, you would have to poll to get the recent number still...
yshui has joined #dri-devel
<jenatali>
WDDM works that way for all devices FWIW, i.e. all fences are timeline fences with that kind of sequence number
<karolherbst>
would be nice if you could just wait on that number to change
<karolherbst>
but...
<karolherbst>
the real solution of course is that the GPU should simply be able to call host code :P
<karolherbst>
but yeah... a second thread isn't necessarily a bad idea
<jenatali>
"Wait on that number to change" == "wait for a fence signal"?
<karolherbst>
mhhh
<jenatali>
And technically the GPU can call host code by raising an interrupt ;)
<karolherbst>
I should just add a future runtime and...
<karolherbst>
in any case, I guess it needs another thread
<jenatali>
You either accept that the thread submitting work to gallium waits for completion, or you put the completion processing on a separate thread, yeah
<jenatali>
Those were the only solutions I came up with at least
<karolherbst>
right...
yshui has quit [Ping timeout: 480 seconds]
<robclark>
karolherbst: I do have userspace fences, ie. just a seqn.. freedreno's fence::wait() will check that before making a syscall
yshui has joined #dri-devel
jkrzyszt has quit [Quit: Konversation terminated!]
coldfeet has joined #dri-devel
epoch101_ has joined #dri-devel
epoch101 has quit [Ping timeout: 480 seconds]
<jenatali>
As it should be
sarnex has quit []
epoch101_ has quit []
coldfeet has quit [Remote host closed the connection]
kts has quit [Quit: Konversation terminated!]
epoch101 has joined #dri-devel
hansg has quit [Remote host closed the connection]
<karolherbst>
it's enough that test_basic seems to be happy
haaninjo has joined #dri-devel
sarnex has joined #dri-devel
epoch101 has quit []
rasterman has quit [Quit: Gettin' stinky!]
Duke`` has quit [Ping timeout: 480 seconds]
Fijxu has quit [Quit: XD!!]
* robclark
looks
<karolherbst>
mhh I think I'll need to rework error handling as well..
<karolherbst>
though might be fine..
Fijxu has joined #dri-devel
<robclark>
it seems to work (at least for a case with no errors)
<karolherbst>
but is it also faster or less stalling?
<karolherbst>
I wonder if davinci resolve still works with that :D that reminds me.. I wanted to look into threaded compiling...
quantum5 has quit [Ping timeout: 480 seconds]
iive has joined #dri-devel
epoch101 has joined #dri-devel
<robclark>
a bit faster, so now I need to find the next bottleneck
<robclark>
freedreno already does threaded compiling ;-)
<karolherbst>
yeah.. but like.. that doesn't help when a lot of time is spent compiling C code to spir-V to nir :D
<karolherbst>
also doesn't help that the compiler gets serialized to fetch the workgroup info
<karolherbst>
anyway, glad to hear it's faster, I might clean it up tomorrow, but I guess it will have to wait for 25.3 now to land
SquareWinter68 has joined #dri-devel
digetx has quit [Remote host closed the connection]
digetx has joined #dri-devel
vliaskov_ has quit [Ping timeout: 480 seconds]
<robclark>
that's fine, at this point I think we'll be follow ToT or cherrypicking, since there are other things in flight ;-)
cef has quit [Ping timeout: 480 seconds]
<karolherbst>
heh, fair
<karolherbst>
robclark: oh btw.. I am considering moving to gpu side timestamp queries for profiling.. not sure if that's properly supported with all drivers
Lyude has joined #dri-devel
<karolherbst>
with iris get_timestamp and get_query_result_resource aren't well.. matching
<robclark>
only thing that is sketchy for fd is qbo, like I mentioned before
<karolherbst>
maybe something similar would work for you?
<karolherbst>
I lose two low bits of precision with that which.. doesn't matter one bit
<robclark>
other than the "on_gpu" part ;-)
<robclark>
at least if I don't spin up a compute shader
<robclark>
the sqe _could_ do it, but we'd need to add a new pm4 packet
<robclark>
so capturing the value on the cpu is fine.. writing it to a pbo/resource is fine.. but for now we need to do the ticks->us conversion on the cpu
<karolherbst>
mhhh right
<karolherbst>
right we've talked about it, and with CL it's all fine, because there is no buffer mechanism in the API and the frontend could just apply a factor
<karolherbst>
just need to know about that factor
cef has joined #dri-devel
<karolherbst>
so `get_time` would just apply that one and everything should be fine
<robclark>
yeah, if you made an optional pctx or pscreen callback to do the conversion, that would work
<karolherbst>
mhh, does it have to be a callback?
<karolherbst>
can't it just be a simple float?
<karolherbst>
or is it more complex than that?
<robclark>
_probably_? Upcoming kernel work to enable IFPC does change the counter that is used for cpu timestamp reads. I don't _think_ we'll need to apply an offset but not 100% sure yet
<robclark>
callback would be more flexible to cover whatever cases
apinheiro has quit [Quit: Leaving]
<karolherbst>
I see
<karolherbst>
also it's not like it's a hot path anyway