ChanServ changed the topic of #dri-devel to: <ajax> nothing involved with X should ever be unable to find a bar
<karolherbst>
jekstrand: my thought
<jekstrand>
Or that we want to have a 2nd u32 atomic which stores the client-visible refcount and assert that never goes below 0
<jekstrand>
And panic! on them if it ever does
<karolherbst>
jekstrand: yolo is actually legal
<karolherbst>
you know why?
Haaninjo has quit [Quit: Ex-Chat]
<karolherbst>
the spec people just draw their turmp card: "Using this function to release a reference that was not obtained by creating the object or by calling clRetainProgram causes undefined behavior."
<karolherbst>
undef behaviour for the win
<karolherbst>
ehh wait
<karolherbst>
I meant the other sentence
<karolherbst>
there was one saying the same about doing it too often
pcercuei_ has quit []
<karolherbst>
or at least I _think_ I was seeing that somehwere
<alyssa>
my new friend:
<alyssa>
git rebase -i main --exec 'ninja -C build'
<karolherbst>
alyssa: it's the best
<alyssa>
its new friend: my m1
<karolherbst>
jekstrand: ehhh.. I think I've dreamt it...
<jekstrand>
karolherbst: It's there, I'm just not sure it's what you think it is.
<karolherbst>
mhhhhhhh could be that I read that sentence different in the past
<karolherbst>
because it could very well mean that
<jekstrand>
This is entertaining...
<jekstrand>
Implementations shall not allow cl_kernel objects to hold reference counts to cl_kernel arguments, because no mechanism is provided for the user to tell the kernel to release that ownership right. If the kernel holds ownership rights on kernel args, that would make it impossible for the user to tell with certainty when he may safely release user allocated resources associated with OpenCL objects such
<jekstrand>
as the cl_mem backing store used with CL_MEM_USE_HOST_PTR.
<karolherbst>
ahh sure
tursulin has quit [Read error: Connection reset by peer]
<jekstrand>
So we can have our own references... except when we can't.
<karolherbst>
userptrs are responsibility of the client to not kill it
rasterman has joined #dri-devel
<karolherbst>
uhdhsauhdsuadasd
<karolherbst>
annoying
ybogdano has joined #dri-devel
<jekstrand>
I'm starting to feel like we should just YOLO it
* jekstrand
looks at clover
<karolherbst>
lol
<karolherbst>
yeah.. maybe
<karolherbst>
but clover just refs everything no matter what
<alyssa>
there might be some negative knowledge here about trying to implement fundamentally unsafe APIs in safe languages..
<jekstrand>
Clover also doesn't use atomics for its reference count so... Maybe not copy that?
<karolherbst>
it doesn't?
<jekstrand>
Oh, no, it does. std::atomic makes everything magic
<karolherbst>
clovers ref counting is even more magic than the code I've written
milek7 has quit [Server closed connection]
milek7 has joined #dri-devel
<jekstrand>
This is spectacular...
<jekstrand>
CL_DEVICE_REFERENCE_COUNT
<jekstrand>
cl_uint
<jekstrand>
Returns the device reference count. If the device is a root-level device, a reference count of one is returned.
<karolherbst>
yeah...
<karolherbst>
I think nobody writing the spec actually took part in writing a CL impl :p
ajax is now known as Guest1088
<karolherbst>
jekstrand: just wrap it with a min(1, val) or whatever :p
<jekstrand>
I'm bothering an ex-colleague at Intel who's deep into OpenCL on LinkedIn. We'll see if he responds or thinks better of it and keeps away. :)
<karolherbst>
:D
<airlied>
karolherbst: I agree with that assessment of spec writers for CL :-P
<karolherbst>
you know what? let's be pragmatic and always return 1 and never free any memory
<karolherbst>
like if anybody would notice anyway
<karolherbst>
or we just always return a random number
* dcbaker
is sad. the panfrost failures seem to be sporadic. They went away for a while, and now they're back :(
<dcbaker>
at this point I'm making the rc, we'll sort out the regressions after that
<airlied>
karolherbst, jekstrand : retain/release device only applies to sub devices
<karolherbst>
airlied: sure... but we could still refcount it
<airlied>
but not for the API
<jekstrand>
airlied: Yes. It only applies to sub-devices but the reference count query is for everyone!
<airlied>
jekstrand: yeah but it's MBO for root devices
<karolherbst>
airlied: you know what would be funny? if the icd extension would allow you to unload platforms
<jekstrand>
airlied: Yes, I know. Spec quote above.
<karolherbst>
luckily it doesn't, but it would be funny
<karolherbst>
(and actually making sense)
* alyssa
yeets valhall into main
<alyssa>
gl2 by the branchpoint? doable? who knows?!
<karolherbst>
alyssa: how much did you plan to sleep?
<alyssa>
karolherbst: I mean I have weston/sway working in my branch, 99% deqp-gles2 pass rate
<alyssa>
more a question of cleaning up 100+ patches and either coercing someone to review or just yeeting into main
<alyssa>
jekstrand: bbrezillon: I assume you'd all rather I do the second at this point ;-p
<jekstrand>
alyssa: yeet away
<alyssa>
;p
<jekstrand>
So long as all it touches is panfrost, I don't care.
<karolherbst>
alyssa: new features ain't regressions, so you can fix bugs after the release, win win
<alyssa>
karolherbst: the kernel does not agree with that take ;-p
<karolherbst>
alyssa: if it's not breaking stuff?
<karolherbst>
then it's not a regression
<karolherbst>
it's really that simple
<karolherbst>
although arguably if you expose more features and they end up changing behavior you might be in trouble I guess
<graphitemaster>
wait until end of day friday before yeeting 100+ patches into the main branch, that's the law
<alyssa>
graphitemaster: lol
<alyssa>
meanwhile I have a h*ck of a rebase ahead of me..
<karolherbst>
do it at the weekend, where nobody is online to stop you
<alyssa>
that, that is an approach
<graphitemaster>
that means you have to work on the weekend
<HdkR>
Same as usual then?
<karolherbst>
just work on weekends then, so that you won't have to work within the week
rasterman has quit [Quit: Gettin' stinky!]
* jekstrand
files a spec bug about CL_KERNEL_PROGRAM with a 0 reference count.
<jekstrand>
We'll see what happens
<airlied>
move to Australia you get a whole day of work when everyone else is on the weekend
<karolherbst>
jekstrand: I am still not convinced it's an actual problem.
ahajda has quit [Read error: Connection reset by peer]
<karolherbst>
jekstrand: so what I think how they thought stuff should work is, that you either get a pointer by creating an object and release it via *Release, or you get a ptr through literally any other mean and call retain on it, and release it later
<alyssa>
airlied: Hmm
test has joined #dri-devel
<alyssa>
that rebase sucked, does it build after? no!
<Sachiel>
push as is with a note: "Making it build is left as an exercise for the reader"
<jekstrand>
karolherbst: I'm now attempting a YOLO approach
nchery has quit [Ping timeout: 480 seconds]
<karolherbst>
jekstrand: sounds like a good idea
<karolherbst>
I think we can manage refcounts just fine internally, and if the client breaks stuff, then stuff breaks
<jekstrand>
Yup
<jekstrand>
I think that's the plan
<jekstrand>
I've got one YOLO reference counting impl. Going to see if I can refine it a bit.
<alyssa>
jekstrand: speaking of all this compute stuff
<alyssa>
panvk compute when? :-p
<jekstrand>
alyssa: It's running deqp right now.
<alyssa>
Woo!
<alyssa>
I helped! ;-p
ngcortes has joined #dri-devel
<jekstrand>
alyssa: I started it yesterday morning so should be done before EOD
<alyssa>
ha HA!
<karolherbst>
jekstrand: but yeah, would be cool to figure all this out and if possible just use one object for everything and I think we can just have it all live inside an Arc
<alyssa>
jekstrand: okay so I give Valhall compiler and you give a Vulkan driver, deal? :-p
<jekstrand>
alyssa: Uh...
<jekstrand>
karolherbst: That's my plan.
<karolherbst>
but anyway, I will probably don't do anything until Monday, but from what I've read in the rust source code, Arc should be sufficient if we just leak the pointer
<jekstrand>
karolherbst: Yup. I just need to figure out how to make it clean and then port the rest of it.
<karolherbst>
cool
<pinchartl>
alyssa: if that's the cost of a shader compiler, I wonder how much an ISP reverse engineering would cost. I'm currently trying to get frames out of an ISP for which I have documentation, and I can't figure it out (yet) :-)
<alyssa>
pinchartl: sweat
<karolherbst>
would be cool, because 99% of my macro was to hide the wrapping :D so we won't need any of that anymore. I still would like to have a macro for those PartialEq impls though I think
lemonzest has quit [Quit: WeeChat 3.4]
<karolherbst>
not really a big fun of comparing all members
<karolherbst>
*fan
<karolherbst>
and we need that impl for containers and such
nchery has joined #dri-devel
<karolherbst>
ahh, and Hash as well
<jekstrand>
karolherbst: Yeah, I think we want some of that but I think we can probably do it as a trait and then do "impl CLObject for _cl_device_id;" instead of the macro invocation.
<karolherbst>
yeah...
<karolherbst>
would be enough to have an trait method for the Arc and just implement everything on top of that one
<alyssa>
incidentally someone asked if I shouldn't use va_ as a prefix for Valhall compiler backend, because VA-API
<alyssa>
not sure it matters, if private compiler backend headers are #included at the same time as a state tracker that Panfrost can never use... you dun goofed
<alyssa>
and anything after the va_ is realistically unique because, again, compiler vs video state tracker
<jekstrand>
The annoying thing is that we either need to use c_repr on the main struct or we need a container_of macro. There are several things that provide container_of but they're in crates. :-(
<alyssa>
va_lower_isel, va_create_h264_context, i don't think they'll collide ;-p
<karolherbst>
jekstrand: you don't need crates for that, but it doesn't matter
<alyssa>
and it looks like the state tracker use vlVa as its prefix, not va_
<jekstrand>
karolherbst: ?
<karolherbst>
we put an Arc around the entire thing
<karolherbst>
and the first field is the dispatch thing
<karolherbst>
and c_repr doesn't really make much of a difference
<jekstrand>
karolherbst: Does rust guarantee pointer matching of the first field?
<karolherbst>
only with c_repr I think
sravn has joined #dri-devel
<krh>
jekstrand: needs #{repr(C)]
<karolherbst>
but so what
<karolherbst>
jekstrand: although.. seems like rust repr is also fine here
<jekstrand>
karolherbst: Yeah, I just didn't know if we wanted to repr the whole thing
<krh>
rust repr doesn't guarantee any kind of layout
<karolherbst>
I think atm it's close to identical, but they want to make changes if needed
<karolherbst>
but... we all know how that will turn out
<alyssa>
changey changey breaky breaky
f11f12 has quit [Quit: Leaving]
<karolherbst>
anyway.. repr(c) doesn't really come with any negative impact
<karolherbst>
and for the code it won't matter
<alyssa>
karolherbst: yeah but C bad! :-p
<karolherbst>
sure
<karolherbst>
but C code will read it
mbrost has joined #dri-devel
<jekstrand>
We have to use repr(C) on the base struct. I was hoping to not have to use it on the other one
<karolherbst>
ohh actually, you are right
<karolherbst>
we don't return the content, we could just return the pointer to the base thing
<karolherbst>
yeah...
<jekstrand>
But if it's not the first thing, the pointer casting to deal with the Arc<Device> or whatever is annoying and tricky
<krh>
(hmm, hastebin got acquire and now adds a sneaky different url when you copy the link...)
<karolherbst>
jekstrand: also... you can just do "*const _" in case lines get too long
* karolherbst
should use _ more often
MrCooper has quit [Remote host closed the connection]
<jekstrand>
karolherbst: Annoyingly, you can't use a macro on a type that's a generic parameter so it's either got to all be macros or we need to be able to assert the offset is 0.
<jekstrand>
karolherbst: I'm thinking c_repr for now and assert sanity
<jekstrand>
Hrm... Asserting sanity is going to require macros too
<jekstrand>
bah
MrCooper has joined #dri-devel
Major_Biscuit has joined #dri-devel
MajorBiscuit has quit [Ping timeout: 480 seconds]
LexSfX has quit []
mbrost has quit []
<alyssa>
AssertionFailed
mbrost has joined #dri-devel
camus1 has joined #dri-devel
frieder has quit [Remote host closed the connection]
camus has quit [Ping timeout: 480 seconds]
cmarcelo has quit [Quit: leaving]
cmarcelo has joined #dri-devel
cmarcelo has quit [Quit: leaving]
cmarcelo has joined #dri-devel
ngcortes has quit [Ping timeout: 480 seconds]
prahal has joined #dri-devel
whald has quit [Remote host closed the connection]
mhenning has joined #dri-devel
craftyguy has quit [Quit: craftyguy]
craftyguy has joined #dri-devel
Major_Biscuit has quit [Ping timeout: 480 seconds]
devilhorns has quit []
shankaru has joined #dri-devel
mbrost has quit [Ping timeout: 480 seconds]
tlwoerner_ has quit []
tlwoerner has joined #dri-devel
gawin has joined #dri-devel
shankaru has quit [Quit: Leaving.]
gouchi has joined #dri-devel
prahal has quit [Ping timeout: 480 seconds]
mattst88_ has joined #dri-devel
camus has joined #dri-devel
camus1 has quit [Remote host closed the connection]
mattst88 has quit [Ping timeout: 480 seconds]
mlankhorst has quit [Ping timeout: 480 seconds]
mclasen has quit [Ping timeout: 480 seconds]
mclasen has joined #dri-devel
sdutt has joined #dri-devel
<airlied>
anholt: any chance of a g41 reboot (if you haven't)
<danvet>
but not sure, never looked at the details
<robclark>
not 100% sure.. but I'd expect pps-producer in mesa would need a way to suppress it.. maybe it already does, idk
<danvet>
I thought we filter before we copy stuff out
<danvet>
so that the counters work as if they don't increase while you're switched out
ahajda has quit [Quit: Going offline, see ya! (www.adiirc.com)]
<danvet>
there's the pmu mode but that's root and global so fine
<robclark>
so there are two cases for counters.. in-app (extensions like amd perf monitor), and global (pps-producer) where separate process is collecting systemwide counters.. for former you want to hide other processes, but latter you want to *somehow* collect the global view
<agd5f>
IIRC, our gfx perf counters are tied to the gfx context in the pipe. I don't think we expose any global counters today.
<robclark>
ahh... lucky
Lucretia-backup has quit [Read error: Connection reset by peer]
<dcbaker>
not the deqp, I know that's expected, but the piglit tests?
Duke`` has quit [Ping timeout: 480 seconds]
danvet has quit [Ping timeout: 480 seconds]
<airlied>
zmike: might know
<zmike>
dcbaker: pick the whole MR
<dcbaker>
zmike: thanks, doing that now!
shashanks has quit [Ping timeout: 480 seconds]
jewins has joined #dri-devel
gouchi has quit [Remote host closed the connection]
thellstrom has quit [Read error: Connection reset by peer]
thellstrom has joined #dri-devel
mvlad has quit [Quit: Leaving]
ramaling has quit [Remote host closed the connection]
ramaling has joined #dri-devel
nchery has quit [Remote host closed the connection]
nchery has joined #dri-devel
unerlige has quit [Remote host closed the connection]
Ryback_ has quit [Remote host closed the connection]
Ryback_ has joined #dri-devel
mattrope has quit [Remote host closed the connection]
mdnavare has quit [Remote host closed the connection]
jhli has quit [Remote host closed the connection]
dolphin has quit [Remote host closed the connection]
unerlige has joined #dri-devel
mdnavare has joined #dri-devel
sdutt has quit [Remote host closed the connection]
dolphin has joined #dri-devel
dt9 has quit [Remote host closed the connection]
aswar002_ has quit [Remote host closed the connection]
rsripada has quit [Remote host closed the connection]
mattrope has joined #dri-devel
sdutt has joined #dri-devel
jewins has quit [Remote host closed the connection]
pzanoni has quit [Remote host closed the connection]
jewins has joined #dri-devel
pzanoni has joined #dri-devel
tursulin has quit [Remote host closed the connection]
dt9 has joined #dri-devel
jhli has joined #dri-devel
tursulin has joined #dri-devel
aswar002 has joined #dri-devel
rsripada has joined #dri-devel
gawin has quit [Quit: Konversation terminated!]
mbrost has joined #dri-devel
kts has quit [Quit: Konversation terminated!]
frankbinns has quit [Remote host closed the connection]
pcercuei has quit [Quit: brb]
pcercuei has joined #dri-devel
thellstrom has quit [Ping timeout: 480 seconds]
mbrost has quit [Ping timeout: 480 seconds]
pcercuei has quit [Quit: Lost terminal]
ngcortes has joined #dri-devel
mbrost has joined #dri-devel
<graphitemaster>
What is the longest data field chain yall have in code, I'm talking about data.data.data, or data().data.data, or data->data->data->data, because I just came across a sixer, data().data->data.data()->data.data
<FLHerne>
That's pretty good
<FLHerne>
I remember there was a complaint about ->base.base.base when the AMD DAL stuff was proposed for merging
ybogdano has joined #dri-devel
linearcannon has quit [Read error: Connection reset by peer]
linearcannon has joined #dri-devel
rasterman has quit [Quit: Gettin' stinky!]
dt9 has quit [Read error: Connection reset by peer]