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

Re: Future of raspberry pi - software related

Sat Feb 01, 2020 7:03 am

jamesh wrote:
Fri Jan 31, 2020 11:22 pm
Any improvements in the 3D result in an overall better desktop experience as that is rendered using the 3D engine.
Has this always been the case ? I thought the use of 3D engine in the desktop was a recent (Pi4) innovation ?
There is also the benefit that this work is all open source, unlike the 3D stuff in the firmware. ANd being open source, means we can start moving away from the closed source firmware completely. The more of the stack that is OSS the better- it reduces the support burden a lot.
TBH I don't really care too much if it is open source or not, I'm more interested in it "just working" and using it than fixing it (as I'm sure it's very big,complex, and has a huge learning curve).

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

gkreidl
Posts: 6355
Joined: Thu Jan 26, 2012 1:07 pm
Location: Germany

Re: Future of raspberry pi - software related

Sat Feb 01, 2020 7:15 am

jamesh wrote:
Fri Jan 31, 2020 11:22 pm

Any improvements in the 3D result in an overall better desktop experience as that is rendered using the 3D engine.
Grab a window by it's title bar and move it around quickly. Watch all that smearing. Better Desktop experience? That's a joke. (Try the same on an older Pi without the 3D stuff for comparison).
Minimal Kiosk Browser (kweb)
Slim, fast webkit browser with support for audio+video+playlists+youtube+pdf+download
Optional fullscreen kiosk mode and command interface for embedded applications
Includes omxplayerGUI, an X front end for omxplayer

jamesh
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 27451
Joined: Sat Jul 30, 2011 7:41 pm

Re: Future of raspberry pi - software related

Sat Feb 01, 2020 7:23 am

Daniel Gessel wrote:
Fri Jan 31, 2020 11:27 pm
PeterO wrote:
Fri Jan 31, 2020 10:42 pm
Considering how "niche" 3D is in the education context I'm surprised they've put as much resource into openGLES, though I guess originally it came pretty much for free in the existing firmware on the earlier PIs.
Hopefully, then, this represents a change and we’ll get some extra attention for 3D graphics.

I want to find an easy way to learn Vulkan (and not use a library that hides Vulkan) - the spec is quite large! Maybe the VK driver will be easy to build as it’s being developed so we can learn along the way?
We spend a lot of money on the 3D - a company called Igali is contracted in specifically to work on the OS 3D drivers.

Still a LONG way to go for the Vulkan drivers - months if not years before anything approaching something usable.
Principal Software Engineer at Raspberry Pi (Trading) Ltd.
Contrary to popular belief, humorous signatures are allowed.
I've been saying "Mucho" to my Spanish friend a lot more lately. It means a lot to him.

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

Re: Future of raspberry pi - software related

Sat Feb 01, 2020 8:59 am

jamesh wrote:
Sat Feb 01, 2020 7:23 am
Daniel Gessel wrote:
Fri Jan 31, 2020 11:27 pm
PeterO wrote:
Fri Jan 31, 2020 10:42 pm
Considering how "niche" 3D is in the education context I'm surprised they've put as much resource into openGLES, though I guess originally it came pretty much for free in the existing firmware on the earlier PIs.
Hopefully, then, this represents a change and we’ll get some extra attention for 3D graphics.

I want to find an easy way to learn Vulkan (and not use a library that hides Vulkan) - the spec is quite large! Maybe the VK driver will be easy to build as it’s being developed so we can learn along the way?
We spend a lot of money on the 3D - a company called Igali is contracted in specifically to work on the OS 3D drivers.

Still a LONG way to go for the Vulkan drivers - months if not years before anything approaching something usable.
Sorry, I recognize 3D gets a fair share of resources. Not a well thought out comment on my part.

I’d be happy to see code that draws a single triangle to start with and see if, maybe, I could get it to draw two. But, if nothing will be available for a couple of years... well, I have to think on that.

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

Re: Future of raspberry pi - software related

Sat Feb 01, 2020 10:47 am

Grab a window by it's title bar and move it around quickly. Watch all that smearing. Better Desktop experience? That's a joke. (Try the same on an older Pi without the 3D stuff for comparison).
Very different when Compositing is on or off in Gentoo64.

Hmm getting the latest Raspbian now, it's a bit old, Sep 2019, update/upgrade could take some time.
Have not tried mesa 19.3.2 on Raspbian.
Failed to download twice, looks like I will need to use Lite and put a desktop on it.
It failed too? ;) oh well wait and try again tomorrow.

Open source drivers make it easier for baremetal guys to figure out how they work.
A few of us want simple 3D stuff without x11/Linux bloat.
I'm more interested in it "just working" and using it than fixing it
Or learning how it works while waiting?
I am happy with slow progress, if it all worked perfectly there would be no time to learn the stuff that does work.
Very big and long, slow progress to learn everything about Linux and 3D graphics.
If it takes 2-3 years to bring Vulkan out that is good.
That should be just enough time to learn OpenGL/GLES 3.1/3.2.
3D resources could be put into a niche educational alternative.
What seems to be lacking is an Unreal or Unity solution.
So disappointed when that Unity Workshop article came out, I don't have a PC at home now, just lots of Pi's.
I had thought about the old Blender which had the game engine.

Been playing with GLSL Shaders for the last few months, Python can use them fine.
So can C, C++ Rust, Go, Free Pascal, BBC Basic and probably more I have not tested.
If there was a 3D game book like the recent Retro Pi games that would be nice.
Now that we have Compute Shaders lots of near Desktop things are now possible.
So much to learn.

Minetest is still open?
Hmm can it use Compute Shaders?
I'm dancing on Rainbows.
Raspberries are not Apples or Oranges

Heater
Posts: 16870
Joined: Tue Jul 17, 2012 3:02 pm

Re: Future of raspberry pi - software related

Sat Feb 01, 2020 12:34 pm

Gavinmc42,
A few of us want simple 3D stuff without x11/Linux bloat.
Linux is not bloat. It's full of useful stuff.

I have done hardware accelerated 3D stuff on the Pi without X11 mind. I used the Qt libs and got it to render straight into frame buffer with GLES. Worked treat.
Memory in C++ is a leaky abstraction .

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

Re: Future of raspberry pi - software related

Sat Feb 01, 2020 11:27 pm

I have done hardware accelerated 3D stuff on the Pi without X11 mind. I used the Qt libs and got it to render straight into frame buffer with GLES. Worked treat.
On a Pi4?
I'm dancing on Rainbows.
Raspberries are not Apples or Oranges

Heater
Posts: 16870
Joined: Tue Jul 17, 2012 3:02 pm

Re: Future of raspberry pi - software related

Sun Feb 02, 2020 2:30 am

No, my Qt 5 and gles experiments were done back in the day on the first model Pi.
Memory in C++ is a leaky abstraction .

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

Re: Future of raspberry pi - software related

Sun Feb 02, 2020 1:26 pm

Kmscube works on Pi4

User avatar
dividuum
Posts: 228
Joined: Sun Jun 16, 2013 1:18 pm
Location: Germany
Contact: Website

Re: Future of raspberry pi - software related

Sun Feb 02, 2020 8:41 pm

My personal software wishlist:

* Not sure if Full KMS is the goal eventually, but right now using KMS instead of dispmanx has massive downsides: It's less flexible with rotating layers (0/180 degree only), the number of layers is limited and changing layer properties is slower so it's not possible to move a layer around smoothly. At least that's what it's been a few months ago. It seems the Full KMS implementation it the bare minimum to get software like Kodi running.

* More documentation on how the hardware decoding for H256 using ffmpeg works. I've worked by way through the patched ffmpeg from last year and got my own software running with that. Now that ffmpeg has an official release in Raspbian, it would be nice if there were more example on how to use it to get decoded frames into MMAL.

* There's still tearing in video playback in dual display configurations. This is being worked on. Looking forward to any testable release.

* A way to synchronize the HDMI vsync for both HDMI ports. Older Pi version has a `vcgencmd hdmi_adjust_clock` command to slowly shift the HDMI output around. With the Pi4 AFAIK it's impossible to make any guarantees about vsyncs. It would be nice to have a way to control that.
info-beamer hosted - A user and programmer friendly digital signage platform for the Pi: https://info-beamer.com/hosted

crossbar
Posts: 45
Joined: Mon May 19, 2014 9:45 am

Re: Future of raspberry pi - software related

Mon Feb 03, 2020 1:09 pm

See this new blog about comming software realted to rasp pi4/VC6 :
https://www.raspberrypi.org/blog/vulkan ... -triangle/

-> Raspberry Pi 4 Model B is now OpenGL ES 3.1 certified / passed Khronos Conformance Tests Suite (CTS)
-> Eben Upton says first beta vulcan will take about half a year.

mic_s
.
Last edited by crossbar on Mon Feb 03, 2020 1:23 pm, edited 1 time in total.

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

Re: Future of raspberry pi - software related

Mon Feb 03, 2020 1:19 pm

crossbar wrote:
Mon Feb 03, 2020 1:09 pm
See this new blog about comming software realted to rasp pi4/VC6 :
https://www.raspberrypi.org/blog/vulkan ... -triangle/

-> Raspberry Pi 4 Model B is now OpenGL ES 3.1 certified.
-> Eben Upton says first beta vulcan will take about half a year.

mic_s
.
Nice! I looked at that post before the 6 month comment was added. Yep, definitely time to start learning Vulkan!

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

Re: Future of raspberry pi - software related

Mon Feb 03, 2020 1:26 pm

Oh joy. Khronos again. With their tri-state bools, pointless Hungarian notation, and bogus C syntax formatting, no doubt.

I'm betting it's as much of a ball-ache to get going as OpenMAX.

jamesh
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 27451
Joined: Sat Jul 30, 2011 7:41 pm

Re: Future of raspberry pi - software related

Mon Feb 03, 2020 1:28 pm

Daniel Gessel wrote:
Mon Feb 03, 2020 1:19 pm
crossbar wrote:
Mon Feb 03, 2020 1:09 pm
See this new blog about comming software realted to rasp pi4/VC6 :
https://www.raspberrypi.org/blog/vulkan ... -triangle/

-> Raspberry Pi 4 Model B is now OpenGL ES 3.1 certified.
-> Eben Upton says first beta vulcan will take about half a year.

mic_s
.
Nice! I looked at that post before the 6 month comment was added. Yep, definitely time to start learning Vulkan!
I'd say 6 months until some sort of early beta release, some more months required to get it full featured and compliant. But that's a guess. Igalia are doing this but also the OpenGLES stuff for VC6 AND VC4, so they have a lot to do.
Principal Software Engineer at Raspberry Pi (Trading) Ltd.
Contrary to popular belief, humorous signatures are allowed.
I've been saying "Mucho" to my Spanish friend a lot more lately. It means a lot to him.

jamesh
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 27451
Joined: Sat Jul 30, 2011 7:41 pm

Re: Future of raspberry pi - software related

Mon Feb 03, 2020 1:30 pm

dickon wrote:
Mon Feb 03, 2020 1:26 pm
Oh joy. Khronos again. With their tri-state bools, pointless Hungarian notation, and bogus C syntax formatting, no doubt.

I'm betting it's as much of a ball-ache to get going as OpenMAX.
Should be a bit easier to use than OpenGL - requires less boiler plate AIUI. Almost everything in the whole world is easier to use than OpenMAX though, which is not a 3D API, so not really comparable.
Principal Software Engineer at Raspberry Pi (Trading) Ltd.
Contrary to popular belief, humorous signatures are allowed.
I've been saying "Mucho" to my Spanish friend a lot more lately. It means a lot to him.

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

Re: Future of raspberry pi - software related

Mon Feb 03, 2020 1:50 pm

No, but a terrible API written by a company doesn't exactly inspire confidence in a second from the same company.

Looking at it, you've now got the boolean type as a simple typedef of a uint32_t, and, on the same page, this monstrosity:

Code: Select all

VkDeviceAddress represents device buffer address values:

typedef uint64_t VkDeviceAddress;
Encoding addresses as integers. Because, as we all know, that worked out *so well* last time...

And yes, more pointless Hungarian notation -- you have a compiler, which handles types: use it -- and their usual

Code: Select all

foo* bar;
idiocy. I'm underwhelmed, to say the least.

jamesh
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 27451
Joined: Sat Jul 30, 2011 7:41 pm

Re: Future of raspberry pi - software related

Mon Feb 03, 2020 2:05 pm

dickon wrote:
Mon Feb 03, 2020 1:50 pm
No, but a terrible API written by a company doesn't exactly inspire confidence in a second from the same company.

Looking at it, you've now got the boolean type as a simple typedef of a uint32_t, and, on the same page, this monstrosity:

Code: Select all

VkDeviceAddress represents device buffer address values:

typedef uint64_t VkDeviceAddress;
Encoding addresses as integers. Because, as we all know, that worked out *so well* last time...

And yes, more pointless Hungarian notation -- you have a compiler, which handles types: use it -- and their usual

Code: Select all

foo* bar;
idiocy. I'm underwhelmed, to say the least.
And yet, here they are, with the worlds leading 3D API, and the next world leading 3D API.

And what wrong with Hungarian notation? Serves its purpose. Nothing to do with the compiler. It's for use by humans.
Principal Software Engineer at Raspberry Pi (Trading) Ltd.
Contrary to popular belief, humorous signatures are allowed.
I've been saying "Mucho" to my Spanish friend a lot more lately. It means a lot to him.

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

Re: Future of raspberry pi - software related

Mon Feb 03, 2020 2:32 pm

jamesh wrote:
Mon Feb 03, 2020 2:05 pm
And yet, here they are, with the worlds leading 3D API, and the next world leading 3D API.
And, I'm sure you'll agree, the world's leading cross-platform video API.
And what wrong with Hungarian notation? Serves its purpose. Nothing to do with the compiler. It's for use by humans.
As used, it's broadly pointless, and doesn't add any value. Worse, if you need to change the type of a variable, you need to change its name. 'Apps' Hungarian notation does have its place, but Khronos use 'Systems' -- as does virtually everybody else -- which is nothing short of visual clutter and is actively problematic when it comes to doing things like moving from a 32b datatype to a 64b datatype. Joel Spolsky has a good write-up at https://www.joelonsoftware.com/2005/05/ ... ook-wrong/, which also covers the bogus declaration style I mentioned.

And I'm sorry, but there's just *zero* justification for encoding addresses into integer datatypes -- even 64b ones. None. We've been there, done that, and struggled for well over a decade fixing the mess it caused when int remained 32b, but void * turned 64b (which could arguably have been solved by a transition from ILP32 to ILP64, but the tradeoffs are large if you do that, and considered too large at the time, hence LP64 and LLP64). Just don't do it.

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

Re: Future of raspberry pi - software related

Mon Feb 03, 2020 2:37 pm

jamesh wrote:
Mon Feb 03, 2020 1:28 pm
Daniel Gessel wrote:
Mon Feb 03, 2020 1:19 pm
crossbar wrote:
Mon Feb 03, 2020 1:09 pm
See this new blog about comming software realted to rasp pi4/VC6 :
https://www.raspberrypi.org/blog/vulkan ... -triangle/

-> Raspberry Pi 4 Model B is now OpenGL ES 3.1 certified.
-> Eben Upton says first beta vulcan will take about half a year.

mic_s
.
Nice! I looked at that post before the 6 month comment was added. Yep, definitely time to start learning Vulkan!
I'd say 6 months until some sort of early beta release, some more months required to get it full featured and compliant. But that's a guess. Igalia are doing this but also the OpenGLES stuff for VC6 AND VC4, so they have a lot to do.
I was hoping Vulkan would be put on the back burner exactly because Igalia has a lot to do, but nope.

I have a number of reasons to switch. YMMV:

I’m trying to get some new projects rolling - might as well start with the up and coming API, rather than learning new features of an old API. Unless a VC4 compatible VK-lite is coming, I’ve got plenty to do on GLES 2.0 paths, as I hope at least one or two projects will be able to run on a Pi 0 (and I’ve got a few Pi3s to make better use of), so I’ll drop GLES 3.X as a target. I hear pointer functionality is being added to Vulkan, so hopefully we’ll see a performant C or C++ -> SPIR-V path, and be able to share more compute code between CPU and GPU (like OpenCL or Metal); I can work on CPU paths for now (which I’ll use for testing, if nothing else). I’m a slow learner; I don’t get far in 6 months. I have other HW I can learn Vulkan on, if I get through learning the concepts. Learning Vulkan opens more doors for me professionally than learning more GLES.

My hope/expectation/assumption is that the Vulkan driver development will start with fairly robust support for writing vertex and pixel shaders, and therefore support some of the stuff I want to do. If compute is added next, it could meet my needs as, so far, I’m not planning to use tessellation or geometry shaders or other advanced features.

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

Re: Future of raspberry pi - software related

Mon Feb 03, 2020 3:03 pm

dickon wrote:
Mon Feb 03, 2020 2:32 pm
And I'm sorry, but there's just *zero* justification for encoding addresses into integer datatypes -- even 64b ones. None. We've been there, done that, and struggled for well over a decade fixing the mess it caused when int remained 32b, but void * turned 64b (which could arguably have been solved by a transition from ILP32 to ILP64, but the tradeoffs are large if you do that, and considered too large at the time, hence LP64 and LLP64). Just don't do it.
I’m not sure exactly how I’d implement a threaded compacting garbage collector without being able to look at bits in a pointer.

However horrible you find Vulkan, it’s looking like it’s here, and here to stay a while.

jamesh
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 27451
Joined: Sat Jul 30, 2011 7:41 pm

Re: Future of raspberry pi - software related

Mon Feb 03, 2020 3:10 pm

dickon wrote:
Mon Feb 03, 2020 2:32 pm
jamesh wrote:
Mon Feb 03, 2020 2:05 pm
And yet, here they are, with the worlds leading 3D API, and the next world leading 3D API.
And, I'm sure you'll agree, the world's leading cross-platform video API.
And what wrong with Hungarian notation? Serves its purpose. Nothing to do with the compiler. It's for use by humans.
As used, it's broadly pointless, and doesn't add any value. Worse, if you need to change the type of a variable, you need to change its name. 'Apps' Hungarian notation does have its place, but Khronos use 'Systems' -- as does virtually everybody else -- which is nothing short of visual clutter and is actively problematic when it comes to doing things like moving from a 32b datatype to a 64b datatype. Joel Spolsky has a good write-up at https://www.joelonsoftware.com/2005/05/ ... ook-wrong/, which also covers the bogus declaration style I mentioned.

And I'm sorry, but there's just *zero* justification for encoding addresses into integer datatypes -- even 64b ones. None. We've been there, done that, and struggled for well over a decade fixing the mess it caused when int remained 32b, but void * turned 64b (which could arguably have been solved by a transition from ILP32 to ILP64, but the tradeoffs are large if you do that, and considered too large at the time, hence LP64 and LLP64). Just don't do it.
Actually, using void * has proven to be big issue with getting 64 bit kernels work on on the Pi range. The firmware on the VC4 is 32bit, which means void * is 32 bits. In ARM space, it will be 32 or 64 depending on the build. This means that structures change size when moving from 32 to 64 bit in ARM space, which break the VC4 API which uses these structures to pass data to and from the GPU. It's taken some quite awkward work to even get close to making the 64bit kernel talk to the 32bit firmware, especially when passing around pointers to memory.

Of course, when the VC range was being developed, well over 10 years ago, on a memory constrained system, 32bits was absolutely fine, so it was never considered to use 64bit pointers on a wholly 32bit system.

So, there's ONE justification for using a very specific size.
Principal Software Engineer at Raspberry Pi (Trading) Ltd.
Contrary to popular belief, humorous signatures are allowed.
I've been saying "Mucho" to my Spanish friend a lot more lately. It means a lot to him.

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

Re: Future of raspberry pi - software related

Mon Feb 03, 2020 3:16 pm

Daniel Gessel wrote:
Mon Feb 03, 2020 3:03 pm
I’m not sure exactly how I’d implement a threaded compacting garbage collector without being able to look at bits in a pointer.
Looking at a pointer in the context of that sort of thing is fine, because it's one, smallish piece of code that's buried in a system library, and can be altered without recompiling your applications. Exposing it to user applications, OTOH, is not, and we have good historical precedent as to why. Ignoring it simply because they can is dreadful practice.
However horrible you find Vulkan, it’s looking like it’s here, and here to stay a while.
I know. That doesn't mean I have to like it. Happily, it isn't the sort of code I'm paid to write, so I doubt I'll need to get much exposure to it. But that won't stop me complaining about the atrocious practices involved: arguably, authors of widely-used APIs should be held to a better standard than the rest of us. This lot are just bad.

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

Re: Future of raspberry pi - software related

Mon Feb 03, 2020 3:27 pm

jamesh wrote:
Mon Feb 03, 2020 3:10 pm
Actually, using void * has proven to be big issue with getting 64 bit kernels work on on the Pi range. The firmware on the VC4 is 32bit, which means void * is 32 bits. In ARM space, it will be 32 or 64 depending on the build.
Yes. What you're doing is trying to mix different sizes in different hardware blocks, and there isn't anything trivial that's going to save you with that: the language wasn't designed for it, and arguably passing addresses between hardware is out of scope.

Conflating pointers and integers within applications -- excluding system libraries like libc and arguably /opt/vc/lib/*, which almost always need to do some pretty grotty things to get everything working cleanly -- OTOH is a very different kettle of fish.

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

Re: Future of raspberry pi - software related

Mon Feb 03, 2020 3:49 pm

dickon wrote:
Mon Feb 03, 2020 3:16 pm
Daniel Gessel wrote:
Mon Feb 03, 2020 3:03 pm
I’m not sure exactly how I’d implement a threaded compacting garbage collector without being able to look at bits in a pointer.
Looking at a pointer in the context of that sort of thing is fine, because it's one, smallish piece of code that's buried in a system library, and can be altered without recompiling your applications. Exposing it to user applications, OTOH, is not, and we have good historical precedent as to why. Ignoring it simply because they can is dreadful practice.
However horrible you find Vulkan, it’s looking like it’s here, and here to stay a while.
I know. That doesn't mean I have to like it. Happily, it isn't the sort of code I'm paid to write, so I doubt I'll need to get much exposure to it. But that won't stop me complaining about the atrocious practices involved: arguably, authors of widely-used APIs should be held to a better standard than the rest of us. This lot are just bad.
Well, my GC is part of my application’s code, but that’s my problem.

I generally don’t complain about the output of standards committees: I didn’t much like the OpenGL ARB meetings I went to and I absolutely hated being in on the early WebGL meetings - mostly I’m not very happy arguing for things I find obvious but seem to elude other people. Even the API design work I do today is frustrating: I create something beautiful and it gets ignored! Design by committee just isn’t any fun - it seems to be this necessary evil sort of thing. And widely accepted standards get produced without (and sometimes despite) my help...

And, so far, Vulkan looks infinitely better than the alternatives.

6by9
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 9929
Joined: Wed Dec 04, 2013 11:27 am
Location: ZZ9 Plural Z Alpha, aka just outside Cambridge.

Re: Future of raspberry pi - software related

Mon Feb 03, 2020 4:25 pm

Khronos only facilitate the development of the spec via Working Groups. They as a company don't write them.
Blame the OpenMaxIL Working Group rather than Khronos for that API - you had about 6 different manufacturers trying to get all of their bells and whistles in, and a number of the basics were overlocked (natural alignment within structures for example).
Software Engineer at Raspberry Pi Trading. Views expressed are still personal views.
I'm not interested in doing contracts for bespoke functionality - please don't ask.

Return to “General discussion”