It's software this time!

[rSl]

As another teaser, this is 3D acceleration and X11 working together using xf86-video-armsoc-omap5 and dri3wsegl - this is not using TILER yet, but that's the next step. The armsoc-omap5 driver also takes advantage of the GC320 2D accelerator.

wow!

 

[levi]

I don't understand fully the state of @daveshah work* (which kernel version and which results if any without proprietary stuff, I don't really care for 3D) but the fact that he is working is good enough.

If you don't care for 3d this won't interest you I think. In his last post where he posted a short video (in either this thread or the older news thread, I can't see from here) he said something about the 2D driver as well, but I assume that's only used for shifting window bitmaps around at the moment. I guess it might also be used by office apps and graphics programs if they are compiled for it, but it won't affect emulated 2d games if that's what you're thinking of running.

I think I'm somewhere in the last batch so I wouldn't probably notice.
But yes, I'd like to have some kind of policy to generalize these cases, which would also be an incentive for new developers.
I don't know who should decide it.
I think it's nice of ED to have asked basically all forum members to vote, in recognition to community, but I find other alternatives also reasonable:
- let ED alone decide (he gets to decide investments in hardware, so a Pyra to a developer could just be a cheaper investment than some he has decided alone)
- have a council of developers decide (so that they can evaluate the develper or his contribution)
- have all preorderers decide (or only those that would have their shipment delayed, so none after @daveshah in this case, maybe I'm after him and I voted)
but it's all academic, because internet elections don't work anyway...


* I don't understand it because I haven't reasearched it, not because any lack of transparency. It's probably out there in a pubilc mailing list and some gits.

I assume ED thinks this is a good idea, because if he poopooed it out of hand he wouldn't have even posted this thread with a poll. He's giving us a veto basically. You could argue he should limit it to the pre-orders already, but that's rather involved when he already has polls in this forum software, and in my case at least I'm not sure he has my current email address associated with my shop account yet; perhaps there's a way I could fix that without placing an order, I'll have to check.

 

[pyrat]

If you don't care for 3d this won't interest you I think. In his last post where he posted a short video (in either this thread or the older news thread, I can't see from here) he said something about the 2D driver as well, but I assume that's only used for shifting window bitmaps around at the moment. I guess it might also be used by office apps and graphics programs if they are compiled for it, but it won't affect emulated 2d games if that's what you're thinking of running.

Accelerating an old boring desktop would be interesting to me _AND_ IIRC that could come from etnaviv (or a part of it, most likely with adaptation required) in all free software, so lovely.
I'm not into games, just like I'm not really into art. I can recognize its beauty but I don't spend much time on it. Once in maybe a decade I get hooked in a game, play it more or less often
for 2-4 months, and that's it. It's possibly more of my defect than my virtue, but I can live with that.

But hey, I don't want Pyra to be good for me only, I want Pyra to be good for everyone. And it must of course play games.

I assume ED thinks this is a good idea, because if he poopooed it out of hand he wouldn't have even posted this thread with a poll. He's giving us a veto basically. You could argue he should limit it to the pre-orders already, but that's rather involved when he already has polls in this forum software, and in my case at least I'm not sure he has my current email address associated with my shop account yet; perhaps there's a way I could fix that without placing an order, I'll have to check.

I understand he may want some input, and setting up a poll is giving participants even less work than if they have to write their opinion. I just hope he's not giving us a real veto, because internet voting is so easy to game. One person jumping the queue is not sooo terribly important, although PR-wise could backfire if ED had not done like he did, but a real veto is still a bit scary. Anybody could set up a few hundred forum users and derail the vote. Census definition is a complex and important part in elections, and internet voting is fundamentally flawed, so it is ok as opinion poll, excuse to write arguments (reading the reasons people have is more important than counting votes with imperfect means, because counting votes can't change one's opinion, and understanding others can, or can at least enlighten), and mostly better than throwing a coin, but not something I would recommend for any important decision.
I realise than even what I just said is too gross an overgeneralisation, but anyway.

In any case I agree. You are right that the cost of refining a census or perfecting an election system is probably excessive for the expected benefit. And that must be taken into account too. I think ED did quite right.

 

[daveshah]

Indeed, the 2D acceleration in xf86-video-armsoc-omap5 is fully open source using etnaviv. It doesn't actually provide a massive performance boost, according to its README purely software rendering on the ARM cores is actually faster (I haven't tried myself yet) but it should be lower power and free up more CPU for other purposes.

Only the kernel-space part of the 3D acceleration is open source, all the magic (including the firmware that runs on the GPU itself) is in the closed-source userspace libraries. It is quite unlikely that the SGX GPU in the OMAP5 will ever see an open source userspace given the amount of reverse engineering work that would be required.

 

[levi]

Yeah, I'm all for lower power when it comes to desktop stuff. Games might need the extra speed, but even with this driver installed they can always write their own code to copy blocks in the framebuffer should they need it. I don't think the OMAP has a blitter to do that does it*?

* I may have been watching too many old 8-bit videos recently.

 

[daveshah]

The GC320 2D core pretty much does blitting, blending, scaling, rotation and colour space conversion as its main operations. In general it is only used for X acceleration so games wouldn't be using it other than for blitting the final rendered game into a window (for which it is plenty fast enough and the reduced CPU time will probably help the game). In theory, it would probably be possible to write an accelerated SDL library using the GC320, but I don't know how much benefit that would bring as I'm not very familiar with the SDL programming model.

The other 2D "acceleration" is in the display controller itself, which has support for mixing multiple "overlays" together to form the final output. From what I've seen of the code, the omap5 X11 driver also uses this to implement the hardware cursor, which gives very responsive cursor movement as a cursor move just changes the start X/Y position of the cursor overlay. The display controller can also do some simple scaling, I think some emulators on the Pandora used this - however the ratios are limited and getting this to play together with hardware rotation would need some care.

 

[kwi]

Very fair and honest question @EvilDragon . Lurking around and honestly admire your work and dedication and of course and obiously voted yes since that helps us all get a better working pyra with less bugs. Also thanks so much for all of the other hard working guys (@daveshah , @aTc , @hns and a bunch I very probably forgot which I'm sorry of). One actually can't say that enough.

 

[elvissteinjr]

As long as it doesn't accidentally change the number of my unit, it's cool. One unit getting pushed out earlier won't make any difference to me anyways.

 

[Xcl4m4t10n]

Stupidiest poll I have ever seen .

 

[pimaster]

I've got a few retail units here already

You casually drop this bomb and try to distract us with a poll about gathering developer assistance?!
You have talked before about paying developers to work on the kernel if you knew who to contact. I'm assuming they would have had to have a unit although I guess that is what previous revisions were for.
Does ED feel concern that it is a production unit that he is now giving away?
I am ok with a 'jump the queue' payment, especially for someone who has demonstrated they can do the job and has already committed to buying the devboard. (I was hoping to be able to do the same thing but Linux source code is kicking my butt)

It is also good to see a large number of people already on board with the idea.

 

[TrashyMG]

I am ok with a 'jump the queue' payment, especially for someone who has demonstrated they can do the job and has already committed to buying the devboard. (I was hoping to be able to do the same thing but Linux source code is kicking my butt)

Kind of wish I had the skills to solve big problems when investing in my OMAP5 Devboard, I ended up just being good at end user things.I guess I did make a few good videos out of it.

 

[Swordfish II]

I thought people working on the software already had priority, if davesha has a skip ticket, shouldn't every other dev also have one ?

I think he was an "unknown" dev who demonstrated how he can definitely help.

 

[levi]

You have talked before about paying developers to work on the kernel if you knew who to contact. I'm assuming they would have had to have a unit although I guess that is what previous revisions were for.

No, one of the most impressive things about this fix that @daveshah did was that he did it just using an OMAP5 devboard. God knows what magic he'll be able to do with an actual Pyra.

 

[Grench]

So, easy yes there. This has been an uncertainty in the project and he seems to have cracked it

Is there any chance this could be a natural lead-in to getting hardware support for H.264 working too?

I'm looking forward to when his stuff gets rolled into the main release OS.

 

[ible]

it's the software, stupid!

glad to see progress in this direction as always. looking forward to seeing what compiles/works on the Pyra

 

[daveshah]

Is there any chance this could be a natural lead-in to getting hardware support for H.264 working too?

For the most part h264 is a totally different subsystem, with quite a few components that will need to be ported, many of which seem to have not been touched since 2013:

- the ipumm firmware that runs on the M4 cores and coordinates the codec engine. Technically this is half open source (the IPC and memory management side) and half closed source (the codec part), but it looks quite tricky to build so hopefully the prebuilt images can be used as a binary blob.
- the kernel modules to load and interface with the M4s, at a minimum omap_remoteproc but maybe omapdce too (if that is needed it would need to be ported to newer kernels)
- an open source userspace library that talks to the M4 firmware via those kernel modules - libdce
- TI's gstreamer plugins that use libdce - gst-plugin-ducati

This is just from a first look, and it is certainly not a small project to get this all working. But unlike the Pandora I think it will be possible to have this all working in the end. And as the OMAP5s CODECs are quite similar to the current automotive SoCs (DRA7xx etc) there should still be some degree of support from TI for these components.

 

[Phlyra]

For the most part h264 is a totally different subsystem, with quite a few components that will need to be ported, many of which seem to have not been touched since 2013:

- the ipumm firmware that runs on the M4 cores and coordinates the codec engine. Technically this is half open source (the IPC and memory management side) and half closed source (the codec part), but it looks quite tricky to build so hopefully the prebuilt images can be used as a binary blob.
- the kernel modules to load and interface with the M4s, at a minimum omap_remoteproc but maybe omapdce too (if that is needed it would need to be ported to newer kernels)
- an open source userspace library that talks to the M4 firmware via those kernel modules - libdce
- TI's gstreamer plugins that use libdce - gst-plugin-ducati

This is just from a first look, and it is certainly not a small project to get this all working. But unlike the Pandora I think it will be possible to have this all working in the end. And as the OMAP5s CODECs are quite similar to the current automotive SoCs (DRA7xx etc) there should still be some degree of support from TI for these components.

Do you teach this stuff/would you ever consider giving lessons?

 

[daveshah]

It's not actually my main field, so I'm not sure how comfortable I would be actually teaching it. But I'd happily work on a thread or set of Wiki articles or something about the low level Pyra software and hardware.

 

[λ the β-Redex Reducer]

I'd happily work on a thread or set of Wiki articles or something about the low level Pyra software and hardware.

That would be great! I think the Wiki would be an especially good place to place info like that. It's where people would expect it and where it's easier to find. On the forums it would just get pushed away eventually.

 

[M-HT]

But unlike the Pandora I think it will be possible to have this all working in the end.

Actually it was working on Pandora, but it wasn't very useful, because Pandora only supports encoding/decoding the baseline profile, while most videos are encoded using main profile (which Pandora doesn't support).

Aside from that, good work.