Etnaviv on Pyra?

[tigerroast]

The recent progress Etnaviv's been making has generated some Phoronix articles, and it's got me thinking. The OMAP5 CPU-board for the Pyra has a Vivante GC320 2D core. Maybe some open-source magic can be worked in?

Now, there's an immediate problem in that, in the master branch on Github, they don't even have the OMAP5 listed as one of the SoCs with a Vivante GPU, even though the i.MX6 SoCs (which powers Novena!) all have GC320 cores.


But, before I get too deep into the feasibility of just running Etnaviv, I also wonder what advantages, if any, this would bring to make it worth the trouble. Sure, that's one less blob to deal with, and I don't think the FOSS-love this community has needs mention. But what could it provide beyond that? Can't TI's drivers already get OpenGL ES 1+2 out of the GC320? Hell, would the GC320 even be used that much? What 2D content would run faster? Some games? Some emulators? The emulators with 2D&3D games would be tricky, I think.

Would open drivers create more opportunities for the GC320 to be utilized more often? In my opinion, if the answer is yes, then this is reason enough to try getting Etnaviv running...unless it's not a tall order to do whatever you want with TI's drivers in the first place. Then the work ends up becoming redundant. Highly appreciated just for being FOSS, but redundant nevertheless. Still, with so many different chips that can take some work off of the CPU (and, in the case of graphics acceleration, do it one better), it only helps to utilize them to their fullest extent, if not squeeze even more power from them.


Maybe, if the stars align and another CPU-board gets made, everyone will abandon the OMAP5 anyway, making this work all for nothing. Maybe, if that happens after Etnaviv has been ported to the OMAP5 and someone who wants to stay on the platform runs into a problem involving 2D graphics, then such a problem would be easier to rectify by one or two forum-goers with the time and skill. Maybe just being able to easily maintain an older system is worth the trouble.

Idk. Thoughts?

 

[slaeshjag]

The GC320 is not OpenGL compatible, not at all.

It can do more rudimentary 2D operations comparable to DirectDraw of the 90's.

 

[pyrat]

The recent progress Etnaviv's been making has generated some Phoronix articles, and it's got me thinking. The OMAP5 CPU-board for the Pyra has a Vivante GC320 2D core. Maybe some open-source magic can be worked in?

I really hope so.

Now, there's an immediate problem in that, in the master branch on Github, they don't even have the OMAP5 listed as one of the SoCs with a Vivante GPU, even though the i.MX6 SoCs (which powers Novena!) all have GC320 cores.

Yes, that needs some work, but seems doable (by someone more clever than me, so that's not very nice to say).
What I really don't know is if the driver works with GC320 alone or it needs the other components present in the supported SOCs.
I hope it is not too much work to make it work. I have this notion the Vivante design is quite modular with the different components (2d, 3d, video) not really very connected, so that
might have been a chance to have the drivers also independent. But I've tried to build the kernel and userspace and my impression is the armada x driver needs mesa. But I really
don't know what I'm doing and I don't have an OMAP5, so I'm best disregarded. If it really needs mesa then maybe there's some trouble porting it to a SOC with GC320 but without
Vivante 3D. I don't know.

But, before I get too deep into the feasibility of just running Etnaviv, I also wonder what advantages, if any, this would bring to make it worth the trouble. Sure, that's one less blob to deal with, and I don't think the FOSS-love this community has needs mention.

The FOSS-love is my main attractive. It's quite strategic to be able to have blobless desktop and scroll (like for browsing). I don't think a RYF Pyra is completely off charts, even as an aftermarket at tehnoethic or thinkpenguin or whereever. I'm not aware of any RYF phone available, new or old. I sure would like one.
[Edit: I meant sold as RYF, I know tinkephones could have candidates, with similar readiness/problems as the Pyra, like WIFI, and 3D acceleration, but without free software 2d acceleration]
It would need a wifi dongle, unfortunately, but still interesting. And for versions without modem it's still interestign this pocket laptop if the
desktop is usable.

But what could it provide beyond that? Can't TI's drivers already get OpenGL ES 1+2 out of the GC320? Hell, would the GC320 even be used that much? What 2D content would run faster? Some games? Some emulators? The emulators with 2D&3D games would be tricky, I think.

I don't know about games, but browsing the web should be faster. (scrolling, compositing, alpha, svg). I guess pdf reading or printing could also be faster, but I've never checked if 2D hardware is used for that.
If you do it with software it'll be slower. If you do it with the PowerVR then you can't use it for other stuff, I guess.
I'm not sure if the 2d functionality is exposed through OpenGL ES [edit: I hadn't read @slaeshjag when I wrote this]. I guess the 3D functions are (PowerVR, not GC320), but maybe the GC320 too ? The etnaviv drivers currently available are for SOCs with some Vivante 3D core, so they may be harder or easier to adapt to a GC320 without any 3D core (harder if you want to distinguish the case where one uses the PowerVR blob or not? no idea).

You can read the vendor publicity on GC320 family, for what is worth.

There is a wikipedia article claiming that etnaviv is above the proprietary vivante driver in some benchmark, but marked "citation needed". So I can't readily tell if it is about 3D or 2D features. It might not apply to GC320 or OMAP5.

Would open drivers create more opportunities for the GC320 to be utilized more often? In my opinion, if the answer is yes, then this is reason enough to try getting Etnaviv running...unless it's not a tall order to do whatever you want with TI's drivers in the first place. Then the work ends up becoming redundant. Highly appreciated just for being FOSS, but redundant nevertheless. Still, with so many different chips that can take some work off of the CPU (and, in the case of graphics acceleration, do it one better), it only helps to utilize them to their fullest extent, if not squeeze even more power from them.

I don't really know, but my impression is that redundancy is not something that ARM processors boast much. I mean they're designed by hooking together IP blocks from different sources, and that may include
some functionality that is in 2 different IP blocks. It can happen. But they're tight on silicon and power, and tend to separate and specialize hardware to preset tasks, so that usually each block as a different function
and optimal experience is when you use them all because the non specialized, gneral purpose computer gear is relatively low performance. For instance the OMAP5432 diagram shows the Tiler (left) and the GC320
(right) and both can do rotation, but I guess it's in different ways and for different purposes. The Tiler must be better for rotating the whole framebuffer and the GC320 for rotating "sprites" or elements to compose ?

But this is only meanigful if you want 100% free software, if you want a blobful system, I guess there'll be proprietary blobs for all IP blocks, so replacing one
proprietary driver for a free one will not get you new features or performance, it will get you more flexibility and freedom. You'll be a little safer and more ready to take advantage of new developments in kernel,
or any free software component, that the proprietary driver writer will probably not follow for long. One blob less is one obstacle less to change, fix, combine or bring in new versions.

So, it depends on what you want. I suppose proprietary drivers for the GC320 already exist, so you could say etnaviv is redundant. But free software drivers give you so much more than
proprietary that it is very hard for me to call that redundant.

Maybe, if the stars align and another CPU-board gets made, everyone will abandon the OMAP5 anyway, making this work all for nothing. Maybe, if that happens after Etnaviv has been ported to the OMAP5 and someone who wants to stay on the platform runs into a problem involving 2D graphics, then such a problem would be easier to rectify by one or two forum-goers with the time and skill. Maybe just being able to easily maintain an older system is worth the trouble.

Idk. Thoughts?

Definetely, being able to keep silicon working with new software is much better than having to buy (and so spend resources, energy, waste and labour) on new silicon.
Also using time honoured hardware gives more chance that bugs are known or solved than buying the latest innovation. The only thing that keeps new silicon in the market
is marketing thought control for the masses and social/corporate pressure to impose newer features and isolate whoever wants to keep old hardware working.

But since I don't have the skills to pull this through it is a little pointless for me to comment. I'll be thankful if someone puts in the effort, that's all. I can't currently afford to pay someone
to do it for me, so I can only wait and see.

 

[Letalis Sonus]

OpenGL 2 and OpenGL ES 2 are all about programmable shaders and the earlier version's fixed function pipelines are hardly fitted for doing 2D-only acceleration in such a restricted way. OpenVG is more likely to fit, but even that requires a beefier Vivante chip like the GC350 - the GC320's target workload is composition, it's a rather specialized chip.

But I think one could surely come up with a custom X acceleration architecture that makes use of it, it should provide exactly what's needed for that as far as I can tell.