alanc has quit [Remote host closed the connection]
alanc has joined #dri-devel
<pinchartl>
karolherbst: strong opinions on rust in general, or on rust in mesa only ? :-)
<karolherbst>
both :P
<pinchartl>
I haven't read the full mail thread, so maybe it was addressed already, but given your statement in the pull request ("I wanted to learn Rust and I was thinking, why not implement OpenCL in it inside mesa and see how nice it would be to use Rust inside mesa."), it could be helpful to summarize what you've learnt through that process
<pinchartl>
the pros and cons, the current issues, the things that went smoothly, the gains rust already brought, ...
<karolherbst>
pinchartl: I was planning to do that on XDC with my rusticl talk
<pinchartl>
I'll try to watch that (I won't be on site)
<pinchartl>
do you plan to talk about what it would talk to remove the unsafe statements in the current implementation ?
<karolherbst>
but yeah.. maybe it makes sense to write something before that though
<karolherbst>
pinchartl: it's probably not possible at all
<karolherbst>
also.. nothing bad about unsafe, you just have to know what you are doing htere
<pinchartl>
from a quick glance at the changes there's lots of unsafe statements without any comment
<karolherbst>
yeah.. mostly dealing with C API pointers
<karolherbst>
"uhh I dereference a C pointer, but I assume it's safe, because the spec says so" or something :P
<karolherbst>
not much we can really do or explain in most places
<pinchartl>
have you discovered areas where unsafe pointed to things that may actually be unsafe ?
<karolherbst>
most of the time it's about "the API spec guarantees it" or "we have to assume the application is not stupid"
<pinchartl>
I'm thinking about lifetime management of objects in particular
<pinchartl>
the second part bothers me more. relying on *anything* not being stupid is generally, well, maybe stupid ? :-D
<karolherbst>
well.. hard to say.. there are a few things in the spec, like you shouldn't take references for objects set on kernel params, but you can still do
<karolherbst>
yeah.. but I implement a C API
<karolherbst>
I have to draw some lines unless I want to make everything unsafe
<pinchartl>
jokes aside, I have nightmares just thinking about introducing rust in the V4L2 subsystem, as life time management of objects is completely broken. there's no need to give it a try to know it will be horrible. in other kernel subsystems, I would assume rust would point to similar issues that may be fixable. trying rust usually provides a good indicator of the quality of the software design. telling
<pinchartl>
about your findings in that area for the mesa code base would be an interesting chapter in your XDC presentation
<karolherbst>
pinchartl: the good thing about Rust is, that it doesn't define lifetime objects at all
<karolherbst>
uhm
<karolherbst>
OpencL I mean
<karolherbst>
there are some structs defined, but mostly data objects
<karolherbst>
lifetime objects like "cl_mem" are just pointers from an API perspective and I can do whatever I want internally
<karolherbst>
but we also return pointers to Arc managed objects and return the Arcs reference count through the API
kts has joined #dri-devel
<karolherbst>
of course the client can just drop it to 0 whenever they wish
<karolherbst>
and in this case our runtime is toast
<karolherbst>
but... that would also mean the application is dysfunctional on literally every CL impl