Page 16 of 16

Re: Future of raspberry pi - software related

Posted: Mon Feb 03, 2020 4:54 pm
by dickon
They've still got the basics wrong in this thing. Take their bool, for example: you have two valid values in a bool, true and false. They're using 32 bits for them, which gives them a few more values that can be expressed in a bool than simply those two, and as it's now a typedef -- not even an enum, which makes much more sense, even if they did get that wrong[0] -- there's an ambiguity.

As I read the spec, you will need to check that any non-core component -- eg. a third-party library which implements some functionality you're interested in using -- claims to handle bools in the same way, or implement everything as a switch () { case true:; case false:; default: exit("Wah!");} (I'm psuedoing). They could have just said 'anything non-zero is true; test for falsity' and been done with it. No ambiguity, everything will work.

But no.

I'll shut up now. I'm always on the lookout for decent APIs, and this is another one from the same group with the same superficial errors that are in OpenMAX that a few minutes' time took to find, which rules it out in my book. Or severely dents it, anyway.


[0] They should have defined that as a OMX_FALSE = 0; OMX_TRUE = 0x7fffffff; or similar, to ensure the 32b size they were clearly after, but still restrict the actual enum to two values (which can be caught and checked at compile-time). They didn't: you had OMX_FALSE = 0; OMX_TRUE = 1; and OMX_BOOLMAX = 0x7fffffff; meaning your bool could, from a compiler's PoV, legitimately have a third state. Nothing was explained about how to actually test for it -- truthness? falseness? both? -- and this is an error they've actually made worse in Vulkan. Names and exact values may be wrong; I've not done anything nontrivial with OpenMAX in a few years now. There are other legitimate ways of doing the same thing which don't have the same shortcomings their approaches do. E&EO.

Re: Future of raspberry pi - software related

Posted: Tue Feb 04, 2020 1:16 am
by Gavinmc42
It looks like there is a way of getting OpenGL and OpenGLES code running on Vulkan, Angle etc.
Probably no point for the VC4?
But as Vulkan will be open source, it will be there for people to play with and try.

Will it be mainstream enough that things like LunarG with have aarch64 versions?
Any Vulkan SDK/tools run on Aarch64 so I can start trying Vulkan on Android 10?
Wait until Godot 4.0 is out?
I’m a slow learner; I don’t get far in 6 months
I know that feeling, shifted to Gentoo64 to learn OpenGL/baremetal 3D coding in 64bit in April 2018.
This morning after an update, Kmscube was working on Gentoo64 Lite, it has taken nearly 2 years.
Still have only a vague idea how it works :oops:
I have no idea what these guys are talking about.

I was hoping Vulkan would come sooner so I would not have to learn OpenGL
And that there would be some nice libs/tools so I would not have to learn Vulkan.
Too much learning, I'm getting old.

Re: Future of raspberry pi - software related

Posted: Tue Feb 04, 2020 4:26 pm
by Daniel Gessel
dickon wrote:
Mon Feb 03, 2020 4:54 pm
They've still got the basics wrong in this thing. Take their bool, for example: you have two valid values in a bool, true and false. They're using 32 bits for them, which gives them a few more values that can be expressed in a bool than simply those two, and as it's now a typedef -- not even an enum
I get it. I probably would have argued for using C99 _Bool... but I’m sure there are caveats.

Since this thread is supposed to be about SW feature requests, I’ll ask that, in whatever timeframe and forms Vulkan arrives on the Pi, that sample code for equivalents of kmscube and glxgears be included (and made widely known) so it’s as easy as possible for everyone to get started with both X-less and X-windowed rendering.

Re: Future of raspberry pi - software related

Posted: Tue Feb 04, 2020 5:15 pm
by ejolson
Daniel Gessel wrote:
Tue Feb 04, 2020 4:26 pm
dickon wrote:
Mon Feb 03, 2020 4:54 pm
They've still got the basics wrong in this thing. Take their bool, for example: you have two valid values in a bool, true and false. They're using 32 bits for them, which gives them a few more values that can be expressed in a bool than simply those two, and as it's now a typedef -- not even an enum
I get it. I probably would have argued for using C99 _Bool... but I’m sure there are caveats.

Since this thread is supposed to be about SW feature requests, I’ll ask that, in whatever timeframe and forms Vulkan arrives on the Pi, that sample code for equivalents of kmscube and glxgears be included (and made widely known) so it’s as easy as possible for everyone to get started with both X-less and X-windowed rendering.
I think this is a great idea that could be applied to things other than Vulcan.

In particular, it would be nice to have a documented set of code examples for the GPIO, SPI, GPU and other specific hardware features of the Pi using the libraries considered best supported. I would be very happy to see examples in both Python and C, so as to cover both ends of the spectrum of languages. Further examples in other languages would be nice too.

While there is already a projects section which is well maintained, projects are goal based, for example, build a robot, make a game and so forth. The idea here is not a project, but instead simple code showing how to get started using a particular hardware feature the easiest way possible.

Re: Future of raspberry pi - software related

Posted: Tue Feb 04, 2020 5:50 pm
by PeterO
Daniel Gessel wrote:
Tue Feb 04, 2020 4:26 pm
Since this thread is supposed to be about SW feature requests, I’ll ask that, in whatever timeframe and forms Vulkan arrives on the Pi, that sample code for equivalents of kmscube and glxgears be included (and made widely known) so it’s as easy as possible for everyone to get started with both X-less and X-windowed rendering.
It would be nice if the existing examples in /opt/vc/src actually worked on a Pi4 !
PeterO

Re: Future of raspberry pi - software related

Posted: Tue Feb 04, 2020 11:35 pm
by Gavinmc42
It would be nice if the existing examples in /opt/vc/src actually worked on a Pi4 !
Kmscube is similar to /opt/vc/src/hello_videocube?
Kms-quads is a smaller version, like hello_triangle?
Is it just similar function examples you are after?

Re: Future of raspberry pi - software related

Posted: Wed Feb 05, 2020 7:18 am
by PeterO
Gavinmc42 wrote:
Tue Feb 04, 2020 11:35 pm
It would be nice if the existing examples in /opt/vc/src actually worked on a Pi4 !
Kmscube is similar to /opt/vc/src/hello_videocube?
Kms-quads is a smaller version, like hello_triangle?
Is it just similar function examples you are after?
Don't know as it doesn't come installed with the OS.
Don't know as it doesn't come installed with the OS.
I just want example code supplied with the OS to work !

PeterO

Re: Future of raspberry pi - software related

Posted: Thu Feb 06, 2020 9:41 pm
by rin67630
rin67630 wrote:
Wed Jan 22, 2020 6:17 pm
jamesh wrote:
Wed Jan 22, 2020 4:37 pm
If anyone fancies having a go at this (or any stuff they think is useful), they are more than welcome. We like good ideas, especially when others do the work that we don't have time to do.
I have promised to try and I'll do my best.
Maybe that?
https://github.com/gitbls/autoAP/blob/master/README.md