User avatar
dickon
Posts: 1423
Joined: Sun Dec 09, 2012 3:54 pm
Location: Home, just outside Reading

Re: Future of raspberry pi - software related

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, 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.

User avatar
Gavinmc42
Posts: 4502
Joined: Wed Aug 28, 2013 3:31 am

Re: Future of raspberry pi - software related

Tue Feb 04, 2020 1:16 am

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.
I'm dancing on Rainbows.
Raspberries are not Apples or Oranges

Daniel Gessel
Posts: 120
Joined: Sun Dec 03, 2017 1:47 am
Location: Boston area, MA, US
Contact: Website Twitter

Re: Future of raspberry pi - software related

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.

ejolson
Posts: 5145
Joined: Tue Mar 18, 2014 11:47 am

Re: Future of raspberry pi - software related

Tue Feb 04, 2020 5:15 pm

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.

User avatar
PeterO
Posts: 5823
Joined: Sun Jul 22, 2012 4:14 pm

Re: Future of raspberry pi - software related

Tue Feb 04, 2020 5:50 pm

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
Discoverer of the PI2 XENON DEATH FLASH!
Interests: C,Python,PIC,Electronics,Ham Radio (G0DZB),1960s British Computers.
"The primary requirement (as we've always seen in your examples) is that the code is readable. " Dougie Lawson

User avatar
Gavinmc42
Posts: 4502
Joined: Wed Aug 28, 2013 3:31 am

Re: Future of raspberry pi - software related

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?
I'm dancing on Rainbows.
Raspberries are not Apples or Oranges

User avatar
PeterO
Posts: 5823
Joined: Sun Jul 22, 2012 4:14 pm

Re: Future of raspberry pi - software related

Wed Feb 05, 2020 7:18 am

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
Discoverer of the PI2 XENON DEATH FLASH!
Interests: C,Python,PIC,Electronics,Ham Radio (G0DZB),1960s British Computers.
"The primary requirement (as we've always seen in your examples) is that the code is readable. " Dougie Lawson

User avatar
rin67630
Posts: 1017
Joined: Fri Mar 04, 2016 10:15 am

Re: Future of raspberry pi - software related

Thu Feb 06, 2020 9:41 pm

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

Return to “General discussion”