frieder has quit [Remote host closed the connection]
<marex>
cphealy: would be nice to see more developers active in the etnaviv project
<cphealy>
agreed
<lynxeye>
I had hoped that people tinkering with the Purism phone would help a bit with this. We've got some good bug reports and testing (which I really appreciate!) from that side, but sadly not much in the way of active developers.
<lynxeye>
I'm also aware that sometimes long review times might scare away people, so I try to improve on that, but my day is also only so long.
<cphealy>
Other than the smaller market share that Vivante GPUs are in, are there any theories on why there's not much in the way of active developers? Anything that could be reasonably changed? (better documentation to onboard new devs perhaps?)
<dv_>
well, time is one factor - at least I am super busy with other projects already
<dv_>
but I also found it difficult to get into the whole thing. it seems to me that you need years of experience with mesa and gallium before you can do anything.
<eery>
Yeah, I'd like to jump into the code, but have no experience with graphics dev or mesa and no idea how I'd approach it
<lynxeye>
Documentation could certainly be improved in some areas. I believe there are lots of little things that are totally obvious to the small number of people working on etnaviv on a regular basis that are hindering progress for newcomers. It's just that it's really hard for me to decide which are those things that need improvement.
<lynxeye>
eery: Reading driver code is a good first step. The gallium interface also has a bit of documentation that can be helpful. Then searching for a small thing to improve that hasn't many dependencies, like improving an edge of the compiler, or making a new texture format work is a good way to learn more.
<lynxeye>
Things get complicated fast once you have to deal with all the asynchronous stuff that makes a real driver fast.
<dv_>
well, what are the big TODOs?
<dv_>
is shader optimization still #1?
<cphealy>
dv_: that probably depends who you ask. Some will say performance while others could say compliance while others could say GLES 3.0...
pcercuei has quit [Quit: brb]
<eery>
yeah, I assume it probably wouldn't be too hard to get some traces from mesa and fill in some missing functionality to support newer GL extensions
<eery>
it's been my experience some applications run almost perfectly with the GL version faked to 3.3, except a few minor visual artifacts
<dv_>
cphealy: a feature matrix would be good, like what nouveau has
<dv_>
with the matrix cells showing that's done and what is left to do
<lynxeye>
dv_: The thing is: etnaviv is a pretty solid GLES2 driver overall. Some people have asked for GLES3 support, but mostly as a checkbox feature, not because they actually needed any of that functionality. Shader optimization is also not the big #1 in most use-cases. The switch to NIR already improved this area a lot and most use-cases aren't even shader limited.
<dv_>
so what's missing compared to the closed source vivante drivers?
<lynxeye>
dv_: In my experience the best way to work on a new feature is have a use-case that's not working (well) today, find out what needs to be done (avoid stalls, implement missing extension, etc.) and look at how to implement it in the driver.
<dv_>
but you need to know what features are not working well
<dv_>
which is why I suggested that list or matrix as seen in nouveau
<lynxeye>
dv_: Mostly GLES3 support, so lots of extensions. Biggest thing is probably integer support and compute in the compiler.
<cphealy>
Would be good to see GLES 3.1 if only for compute shader support. Then people can use etnaviv for machine vision use cases using TensorFlow Lite for example.
<cphealy>
ha
<eery>
from the perspective of a "desktop user", you run into the lack of GLES3 support pretty often, e.g. no WebRender in firefox
<dv_>
btw, what about vulkan? don't vivante GPUs support that?
<lynxeye>
dv_: Sorry, but I also only find out which features aren't working well when I apply that specific workload to the driver. I don't have a big list of broken things handy. ;)
pcercuei has joined #etnaviv
<lynxeye>
dv_: The big GC7000 parts have all the hardware capabilities you need for vulkan, I just fear that it won't be the magic bullet that people think it is. The OpenGL driver does lots of things behind the API users back to make things fast on this hardware, which is in stark contrast to the vulkan design. So app developers would need to know even more about the Vivante GPU architecture to make things run as well as on OpenGL, which do
<lynxeye>
really mix with relatively tiny market share.
<dv_>
oh indeed, vulkan is super verbose
<dv_>
it is pretty much bare to metal, which in turn is a double edged sword
sravn_ has quit []
<marex>
lynxeye: I can tell you that asking for input on how to debug problem for half a year and being ignored or getting totally worthless feedback can be utterly off-putting
<marex>
so maybe that is one of the problems
<marex>
and there is zero documentation, so onboarding anyone is just ... forget it
sravn has joined #etnaviv
mvlad has quit [Remote host closed the connection]
lynxeye has quit [Quit: Leaving.]
frieder has joined #etnaviv
frieder has quit [Remote host closed the connection]