mlankhorst has quit [Read error: No route to host]
iive has joined #dri-devel
gawin has quit [Ping timeout: 480 seconds]
rgallaispou has quit [Read error: Connection reset by peer]
<jekstrand>
karolherbst: I don't think so. One thing that macro does is assert that the CLObjectBase and T pointers are the same. That can't be done with "where Self"
shankaru has joined #dri-devel
itoral has quit []
swivel has joined #dri-devel
pelmeeris has joined #dri-devel
<karolherbst>
jekstrand: yeah.. I noticed it a bit later as well
<jekstrand>
But, still, the macro is down to two very straightforward functions. Seems a lot more sane than a struct, impl, and half-dozen traits.
<karolherbst>
jekstrand: atm looking at making queue Send and Sync.. but it seems like there are some deeper issues I did ignore :D
<karolherbst>
I am still wondering if we should keep PartialEq and Eq inside the macro, simply for consistency and having it available for all objects
pjakobsson has joined #dri-devel
<karolherbst>
the only issue I still have to figure out is Receiver and Sender not being Sync
<jekstrand>
karolherbst: idk. I thought about it. The one or two places where it was needed, I just used pointers.
pjakobsson_ has quit [Ping timeout: 480 seconds]
<karolherbst>
it does have implicit perf implications though
<jekstrand>
I don't really like the hash sets anyway. I don't have a better plan yet. I just don't like them. :P
<karolherbst>
It also matters for dedup
<karolherbst>
uh... dedup only compares consecutive things.. argh
<karolherbst>
jekstrand: anyway.. functions like dedup could throw out objects which have equal values, but are just different objects
<karolherbst>
and that's something we can't really allow
<karolherbst>
so overwriting PartialEq and Eq is kind of required to stay conformant
fxkamd has joined #dri-devel
<karolherbst>
contains also checks for equality not identity
<karolherbst>
so if we have 4 identical kernels...
<karolherbst>
that's more or less my main reason to just have it for all objects
gawin has joined #dri-devel
<karolherbst>
jekstrand: anyway.. I will keep a rusticl/main and rusticl/wip branch
<jekstrand>
karolherbst: Have you promoted the new wrappers to main?
<karolherbst>
yeah
rgallaispou has joined #dri-devel
heat has joined #dri-devel
<jekstrand>
Cool. I'm probably going to do some more IMG review today and a bit of panvk and then I may get back to rusticl. Anything in particular, I should be jumping on? We kind-of need kernels to work before we can do much more.
<jekstrand>
Unless I wanted to look at de-duplication deeper
jewins has quit [Ping timeout: 480 seconds]
<karolherbst>
heh
<karolherbst>
there is unique() on iter, but it requires Clone + Eq + Hash :/
kts has joined #dri-devel
<karolherbst>
ehh wait, that's a crate
aravind has quit [Ping timeout: 480 seconds]
<karolherbst>
jekstrand: I think you have to accept, that Rust just uses HashMaps/HashSets for this kind of stuff. Crates are doing the same
macromorgan has joined #dri-devel
pjakobsson has quit [Remote host closed the connection]
<jekstrand>
karolherbst: Yeah, that's fine I guess.
<karolherbst>
mhh, we also have to add Hash to the macro, otherwise it can cause random problems ... oh well... it could have been worse
<jekstrand>
karolherbst: If we don't want to open-code de-dup everywhere, we can make the vec_from_arr or whatever I called it helper take a bool dedup parameter.
<karolherbst>
mhhh
mbrost has quit []
<karolherbst>
the issue is, sometimes we have to dedup inside the final container
mbrost has joined #dri-devel
<karolherbst>
like when collecting all kernels for all devices in a program
<karolherbst>
but yeah.. we could add such a parameter I guess
<karolherbst>
although I am not sure if we really have to do it...
<karolherbst>
"Duplicate devices specified in devices are ignored." only thing I found in the spec
<karolherbst>
that's for clCreateContext
fxkamd has quit []
rkanwal has quit [Ping timeout: 480 seconds]
ppascher has quit [Quit: Gateway shutdown]
<karolherbst>
uhh.. adding !Clone and !Copy might make sense as well as this is something we really have to make sure never happens
ppascher has joined #dri-devel
<karolherbst>
ehh wait.. one has to derive that anyway
ybogdano has joined #dri-devel
<karolherbst>
jekstrand: one fun issue to figure out is why math_brute_force tests are crashing randomly
<karolherbst>
ehh wait.. that was a use after free in the CTS... :/
Duke`` has joined #dri-devel
jewins has joined #dri-devel
mclasen has quit [Ping timeout: 480 seconds]
frieder has quit [Remote host closed the connection]
<karolherbst>
jekstrand: I think I will implement running a kernel at the weekend or so.. should be doable.. I hope
FireBurnUK has joined #dri-devel
FireBurn has quit [Read error: Connection reset by peer]
<karolherbst>
jekstrand: if you are up to it you could implement some of the image stuff. Those tests don't depend on kernels afaik
<karolherbst>
like implementing clEnqueueMapImage etc..
<karolherbst>
or I deal with that and you look into kernels :D
<jekstrand>
right
<jekstrand>
Right now I'm trying to keep IMG from committing NIR sins. :)
<karolherbst>
:D
<karolherbst>
have fun
pelmeeris has quit [Remote host closed the connection]
oneforall2 has quit [Remote host closed the connection]
oneforall2 has joined #dri-devel
gouchi has joined #dri-devel
slattann has joined #dri-devel
mbrost has quit [Remote host closed the connection]
mbrost has joined #dri-devel
rkanwal has joined #dri-devel
Guest1678 has quit [Ping timeout: 480 seconds]
nchery has quit [Ping timeout: 480 seconds]
sdutt has quit []
sdutt has joined #dri-devel
lynxeye has quit []
rcf has quit [Quit: WeeChat 3.2.1]
OftenTimeConsuming has quit [Remote host closed the connection]
OftenTimeConsuming has joined #dri-devel
<karolherbst>
jekstrand: the only thing which I dislike about the new wrapper is the slight overhead for CLInfo :/ but there might be a way by improving cl_prop...
<jekstrand>
karolherbst: You mean handling reference counts as a special case?
<karolherbst>
no, I meant that Arc::as_ptr *::from_ptr dance
<jekstrand>
For fetching the reference count?
<jekstrand>
I'm still confused
<karolherbst>
I'd like to just write cl_prop::<cl_context>(&prog.context) for CL_PROGRAM_CONTEXT
<jekstrand>
Oh, for getting objects
<karolherbst>
yeah
<karolherbst>
but I think we could have an abstract impl for those with where...
<karolherbst>
potentially
<jekstrand>
Yeah, maybe
<karolherbst>
will try it out at least
<jekstrand>
I thought about having a cl_context::from_ref() which does that dance
<jekstrand>
But the reference counting situation is horrible
<karolherbst>
yeah, it is
<jekstrand>
The fact that CL gives you a reference sometimes is just a disaster
<karolherbst>
well.. the spec was written with C in mind :/
<jekstrand>
I mean more that you shouldn't hand back a pointer and not hand back a reference
<jekstrand>
It's all kinds of messed up
<karolherbst>
mhh, true
gawin has quit [Ping timeout: 480 seconds]
idr has joined #dri-devel
<ajax>
glXMakeCurrent says it's not legal to call it between glBegin and glEnd
<ajax>
i'm... not really seeing any code that enforces that?
rcf has joined #dri-devel
shankaru has quit [Quit: Leaving.]
<ajax>
literally no code on the client side that ever ends in raising GLXBadContextState
tarceri_ has joined #dri-devel
<ajax>
server side will raise it in a couple of cases, for indirect contexts, which you're not using
nchery has joined #dri-devel
<ajax>
and weirdly only GLX has that constraint, EGL is silent on whether makecurrent is legal between begin/end
<ajax>
which i guess makes sense since gles doesn't have begin/end at all
tarceri has quit [Ping timeout: 480 seconds]
<idr>
I guess that makes sense... being that GLX nominally buffers the data between begin / end.
<HdkR>
But you can use GL with EGL. Sounds like an oversight?
<ajax>
HdkR: that's new in EGL 1.4, believe it or not
nchery has quit [Ping timeout: 480 seconds]
<airlied>
if you use egl and begin/end, it's a hole you deserve to fall down :-P
<HdkR>
Oh jeez. I guess I never looked at an EGL version <1.4
<ajax>
egl 1.3 was december '06 so i suppose you're forgiven for not knowing that
<HdkR>
Fits, I only looked at EGL once ES 3.0 was a thing
<ajax>
well. glx technically says calling any glx function in begin/end is undefined so the current yolocode is perfectly legal
<ajax>
good. i can go back to not caring about this.
MajorBiscuit has quit [Quit: WeeChat 3.4]
mclasen has joined #dri-devel
ngcortes has joined #dri-devel
<HdkR>
oop, I just noticed that intel_clflush is being used on ARM hosts if you're building iris. Not sure if this was fixed in a newer version of mesa.
<HdkR>
Will check once I get my local build done
<jekstrand>
HdkR: Not sure what GPU you're planning to use that driver build on...
<HdkR>
It's something that'll need to be fixed regardless :)
<jekstrand>
Eventually, sure, but i915 doesn't even build on ARM so...
<jekstrand>
I guess if someone wants to run shader-db on their M1 laptop
<dcbaker>
daniels: (or others) has there ever been any attempt to add automatic labeling to gitliab issues?
<HdkR>
Luckily I can ignore kernel space.
<jekstrand>
dcbaker: mslusarz wrote a script. Last I checked, we just never got around to figuring out where to host it.
<dcbaker>
that would be super useful for us (Intel)
<dcbaker>
and me, in particular :)
<jekstrand>
It'd be useful to everyone. We just need to figure out hosting. Maybe daniels know why it stalled?
<karolherbst>
although not sure if I should drop that from_ptr, but including it gets complicated :/
<jekstrand>
karolherbst: I kind-of like having cl_context involved
<karolherbst>
I was thinking of adding a new trait to reverse the order, so the argument given can be something else, but I need to think about it a bit more
nchery has joined #dri-devel
kts has quit [Ping timeout: 480 seconds]
<dcbaker>
Oh, by the way, Jussi promised we'd get the structured sources work into meson 0.62, so that should make bindgen easier
<dcbaker>
and the proc-macro stuff landed for 0.62 as well
nchery has quit [Ping timeout: 480 seconds]
nchery has joined #dri-devel
<idr>
HdkR: And it's really a problem with indirect rendering... which EGL doesn't do at all.
JohnnyonFlame has joined #dri-devel
<HdkR>
Oh right, indirect is a thing
jkrzyszt has quit [Ping timeout: 480 seconds]
mclasen has quit [Ping timeout: 480 seconds]
csileeeeeeeeeeeeeeeeeeeeeeeeoe has joined #dri-devel
<daniels>
dcbaker, jekstrand: yeah, there has - if someone can make https://gitlab.freedesktop.org/freedesktop/mr-label-maker into something with the usual workflow - CI pipeline builds a tagged container, container executes the entrypoint which checks for something to do, sleeps a minute, checks for something to do, etc - I'll get that deployed
<daniels>
just not getting wide enough time slots to make that happen :(
mhenning has joined #dri-devel
mclasen has joined #dri-devel
leah has joined #dri-devel
lemonzest has quit [Quit: WeeChat 3.4]
rasterman has quit [Quit: Gettin' stinky!]
tobiasjakobi has joined #dri-devel
tobiasjakobi has quit [Remote host closed the connection]
<dcbaker>
daniels: I can probably justify working on that. Are there any docs on what needs to happen?
<daniels>
dcbaker: hmmm, not really. I think it's mostly: if you give me a repo which produces a container which a) runs infinitely until it crashes doing the thing it's supposed to do, and b) takes access token + repos to monitor + tagging rules as a config file, then I can make that happen quickly
<dcbaker>
daniels: okay, I'll see what I can do
<daniels>
dcbaker: <3
<daniels>
I'd so appreciate it, thankyou
<dcbaker>
well, I need to be able to extract issues that apply only to intel drivers through the rest (or that other) API, so having something automatically create the tags is pretty important
<dcbaker>
lol
pendingchaos has quit [Remote host closed the connection]
pendingchaos has joined #dri-devel
<dcbaker>
Anyone have last minute objections to 22.0.0 getting released today?
LexSfX has quit [Read error: Connection reset by peer]
<Sachiel>
yes, it should have been released on feb 22. Got get a time machine
LexSfX has joined #dri-devel
pendingchaos_ has joined #dri-devel
pendingchaos has quit [Read error: Connection reset by peer]
pendingchaos_ is now known as pendingchaos
<dcbaker>
Sachiel: blame covid
<FLHerne>
nah, that's last year's excuse, disruptions resulting from the Ukraine crisis is the 2022 one
cphealy has quit []
<Sachiel>
dcbaker was waiting for covid to stop being cool before he got it himself
<dcbaker>
FLHerne: I watied until just before the Invasion of Ukraine started so I wouldn't have a conflict
<icecream95>
New Zealand has been waiting for covid to stop being cool before trying to give it to all of us
<HdkR>
dcbaker: No complaints from FEX-Emu side. With how little that matters :P
<dcbaker>
HdkR: thanks! Always happy for a lack of complaints :D
<daniels>
icecream95: unlike NZ to be slightly behind the curve!
cphealy has joined #dri-devel
Guest1387 has quit [Remote host closed the connection]
ahajda has quit [Quit: Going offline, see ya! (www.adiirc.com)]
jernej has quit [Remote host closed the connection]
jernej has joined #dri-devel
dreda has joined #dri-devel
dreda is now known as Guest1725
Guest1725 is now known as dreda
Duke`` has quit [Ping timeout: 480 seconds]
<karolherbst>
"Returns a semi-colon separated list..." ....
<dcbaker>
karolherbst: cmake?
<karolherbst>
OpenCL
<karolherbst>
apparently returning a semi-colon separated list for the kernels in a program was at some point a smart idea...
<dcbaker>
Well, as long as they dont also return a semi-colon separated mapping...
tanty has quit []
mvlad has quit [Remote host closed the connection]
tanty has joined #dri-devel
tanty has quit []
tanty has joined #dri-devel
<jekstrand>
karolherbst: tf?
<jekstrand>
dcbaker: If you went and made that happen, I would be forever grateful!
<airlied>
HdkR: got an arm board I can plug an intel card into? :-P
<HdkR>
airlied: Sure. Slap it in an Solidrun or Nvidia Xavier
gawin has joined #dri-devel
<HdkR>
Tegra Jetson Orin will also have a release date this month with GTC coming up
<HdkR>
I'm planning on throwing a few Radeons in my Ampere Siryn server once it crops up. If kernel and userspace is ready then Maybe I'll throw an Intel GPU in it.
<karolherbst>
jekstrand: yeah....
<agd5f>
HdkR, PCIe can be a problem on ARM. the two big problems are: 1. some platforms don't support cache coherency with the CPU (required by the PCI spec) 2. platforms don't allow general remapping of PCI BARs for CPU access
<HdkR>
agd5f: Luckily I don't care about those platforms
<HdkR>
Xavier and Ampere Computing doesn't have this problem
<HdkR>
Solidrun maybe?
<HdkR>
I recall someone had some issues with radeon there but I think it was some random kernel bits that got resolved.
csileeeeeeeeeeeeeeeeeeeeeeeeoe has quit [Remote host closed the connection]
<HdkR>
I'll never advocate for someone to buy a Raspberry pi and try to stick a dGPU on to it.
pnowack has quit [Quit: pnowack]
heat has quit [Remote host closed the connection]
heat has joined #dri-devel
<agd5f>
HdkR, lots of random ARM systems are missing whatever IP bits are required
<HdkR>
Aye. Those platforms are basically limited to NVMe storage.
<HdkR>
and wifi
<zmike>
dcbaker: \o/
* dcbaker
is just glad to have the .0 out the door
<mattst88>
\o/
<mattst88>
bumped in Gentoo :)
rgallaispou has quit [Ping timeout: 480 seconds]
rkanwal has quit [Ping timeout: 480 seconds]
<dcbaker>
mattst88: \o/
ngcortes has quit [Ping timeout: 480 seconds]
<ccr>
\o\
JohnnyonF has joined #dri-devel
JohnnyonFlame has quit [Ping timeout: 480 seconds]
rasterman has joined #dri-devel
gouchi has quit [Remote host closed the connection]