Raspberry Pi 4 achieves Vulkan 1.1 conformance, gets GPU performance boost(cnx-software.com)
cnx-software.com
Raspberry Pi 4 achieves Vulkan 1.1 conformance, gets GPU performance boost
https://www.cnx-software.com/2021/10/27/raspberry-pi-4-achieves-vulkan-1-1-conformance-gets-up-to-60-gpu-performance-boost/
151 comments
The statement "the software we use is up to 100 times slower than it needs to be" is not OS overhead (which is relatively small) but about user-facing application software written to optimize development speed/cost and not performance.
A reasonable game is performance focused and is spending most of the computing power directly on itself (even if perhaps not optimally and not utilizing specific GPU hardware to its full extent) and not in OS routines, so an OS providing a specific "game mode" with only the bare minimum amount of OS the game needed to run can perhaps bring a 5% or 10% performance improvement, but not 50% and definitely not 100 times performance increase.
For software that was written in a performance insensitive way (i.e. not games) you perhaps could achieve a 100 times performance increase by a full rewrite avoiding various overheads. However, you would not really need an OS change for that, the main performance-relevant changes would be in the app itself and you can get almost all of that by running the optimized app on a standard OS - but you would need a rewrite of all the actual software.
The example of this article about UnrealEngine and Vulkan is a good illustration - a game targeting the specific hardware directly could achieve the same performance (and more!), however, they are not going to, nobody is going to rewrite the game because that's expensive, so getting an OS abstraction layer like Vulkan - which inevitably adds some extra performance overhead, not reduces it - is the only reasonable way to go.
A reasonable game is performance focused and is spending most of the computing power directly on itself (even if perhaps not optimally and not utilizing specific GPU hardware to its full extent) and not in OS routines, so an OS providing a specific "game mode" with only the bare minimum amount of OS the game needed to run can perhaps bring a 5% or 10% performance improvement, but not 50% and definitely not 100 times performance increase.
For software that was written in a performance insensitive way (i.e. not games) you perhaps could achieve a 100 times performance increase by a full rewrite avoiding various overheads. However, you would not really need an OS change for that, the main performance-relevant changes would be in the app itself and you can get almost all of that by running the optimized app on a standard OS - but you would need a rewrite of all the actual software.
The example of this article about UnrealEngine and Vulkan is a good illustration - a game targeting the specific hardware directly could achieve the same performance (and more!), however, they are not going to, nobody is going to rewrite the game because that's expensive, so getting an OS abstraction layer like Vulkan - which inevitably adds some extra performance overhead, not reduces it - is the only reasonable way to go.
Maybe it's because I've been on Windows for too long, but people are always complaining about how terrible Windows 10 (and soon to be 11 is) as an experience (See recent slowdown with AMD processors). That and a little bit too much time watching all the cool things people did with 1mhz processors with no L1 cache or graphics, on 80s computers. As someone who wasn't around during that time, it's easy to get the feeling that a 1.5ghz quad core cpus +.5ghz gpu should absolutely slay any program, but in my experience using the RPI4 as a primary computer it hasn't felt that way.
> For software that was written in a performance insensitive way (i.e. not games) you perhaps could achieve a 100 times performance increase by a full rewrite avoiding various overheads. However, you would not really need an OS change for that, the main performance-relevant changes would be in the app itself and you can get almost all of that by running the optimized app on a standard OS - but you would need a rewrite of all the actual software.
I think this is insightful. I agree that not everything would be 100x, but I feel like at the level of an RPI 4 even a 5-10% improvement that bumps a game into 30 or 60fps territory would be noticeable. And even a 2x improvement in regular apps would have impact.
> For software that was written in a performance insensitive way (i.e. not games) you perhaps could achieve a 100 times performance increase by a full rewrite avoiding various overheads. However, you would not really need an OS change for that, the main performance-relevant changes would be in the app itself and you can get almost all of that by running the optimized app on a standard OS - but you would need a rewrite of all the actual software.
I think this is insightful. I agree that not everything would be 100x, but I feel like at the level of an RPI 4 even a 5-10% improvement that bumps a game into 30 or 60fps territory would be noticeable. And even a 2x improvement in regular apps would have impact.
The reason you feel RPi4B aren’t performing is because it’s running software written using 2010s and 2020s software standards, languages and runtimes.
Before 2000, many many commercial games and software were written using “classical” C/C++ and had any performance critical areas written in assembly language. People would actually profile their apps and optimize their code and loops. Most any language that had large runtimes or included a garbage collector was not considered an option. Only the most complex, data oriented or GUI oriented parts of the code would be written in high level language. A good example of this mixed language code base is the Allegro 4.x Game Programming Library for DOS, Linux, and Windows.
Going back further into the 80s and 90s, many many commercial games and software were written in all assembly language. Look at the old MS DOS code bases on GitHub for a reference.
All that to say that modern software does a ton things in periphery that old software considered superfluous. We know some of it makes easier to write software, or that the software is more secure, or that it can take advantage of the features of the hardware old machines didn’t have. However, that is still extra code that needs run, often in (event) loops which multiples the amount of time dedicated to that code.
Look at codegolf or other minimal code challenges to see what could be accomplished with a different programming process.
Before 2000, many many commercial games and software were written using “classical” C/C++ and had any performance critical areas written in assembly language. People would actually profile their apps and optimize their code and loops. Most any language that had large runtimes or included a garbage collector was not considered an option. Only the most complex, data oriented or GUI oriented parts of the code would be written in high level language. A good example of this mixed language code base is the Allegro 4.x Game Programming Library for DOS, Linux, and Windows.
Going back further into the 80s and 90s, many many commercial games and software were written in all assembly language. Look at the old MS DOS code bases on GitHub for a reference.
All that to say that modern software does a ton things in periphery that old software considered superfluous. We know some of it makes easier to write software, or that the software is more secure, or that it can take advantage of the features of the hardware old machines didn’t have. However, that is still extra code that needs run, often in (event) loops which multiples the amount of time dedicated to that code.
Look at codegolf or other minimal code challenges to see what could be accomplished with a different programming process.
> OS written just for the RPI4
Linux and NetBSD can be configured to be as good as if they were written just for RPI4.
Linux and NetBSD can be configured to be as good as if they were written just for RPI4.
Mouse and keyboard are as standard and supported as they can possibly be, and the official Raspberry Pi ones are ordinary USB ones supported everywhere. Touchscreens supported in Linux are supported well out of the box as well (e.g. my Dell ones). "100 times slower" sounds like nonsense to me; huge numbers of people are motivated to make software faster, so if there was that much room to improve, it mostly would have happened already.
Yes, I recently was investigating USB keyboard/mouse usage on a microcontroller and found out it's not too difficult to implement: https://www.networktechinc.com/usb-prots.html
>code making use of the fact that we are running on known hardware
>you focused on supporting the official raspberry pi keyboard, mouse, and touchscreen you could circumvent a lot of the pains around driver issues
I'm afraid that's how closed, non-extensible systems are born, and later inevitably die.
>you focused on supporting the official raspberry pi keyboard, mouse, and touchscreen you could circumvent a lot of the pains around driver issues
I'm afraid that's how closed, non-extensible systems are born, and later inevitably die.
I agree. But the context of this is around a solo developer doing this as a hobby OS. And these constraints would help the project have reasonable scope assuming no-one else expressed any interest in it.
Just checked, looks like Vulcan under DRM on the Pi4 works, and at least some people in the Libretro ecosystem have already messed around with it, so this could benefit Lakka. Awesome. Maybe this'll mean getting to play with some decent CRT shaders on the Pi without an unacceptable performance hit, and/or getting to make better use of Retroarch's advanced input lag reduction features.
CRT Royale running 60 fps in a sub 15 W machine would be impressive. 1080p would be nice, 1440p would be great, and 4K would be best. The pi4 can output 4K60, but I really doubt it can shove through that many simulated pixels.
It’s still pretty astonishing to me that it can squeeze 4K60 out at all.
> Maybe this'll mean getting to play with some decent CRT shaders on the Pi without an unacceptable performance hit
Vulkan is mainly about reducing CPU overhead, don't expect it to do much for complex shaders or other things that are already GPU-bound.
Vulkan is mainly about reducing CPU overhead, don't expect it to do much for complex shaders or other things that are already GPU-bound.
If this could get playstation emulators using vulkan running at decent frame rates that would be really, really awesome
I had decent success with PS1 games on the Pi2, which surprised me. Most games I tried ran well. I haven't tried on the Pi4 but I assume it's really good, based on that. PS2 might even work well, there.
N64 was another story, but N64 emulators have improved a bunch since last time I tried. I think the only game I found that played acceptably on the Pi2 was Mario64. Most of the rest were slideshows or didn't run at all.
N64 was another story, but N64 emulators have improved a bunch since last time I tried. I think the only game I found that played acceptably on the Pi2 was Mario64. Most of the rest were slideshows or didn't run at all.
If only there was a world where Apple would sell M1 chips separately from their walled garden.
Well, number one, why would they? Apple makes money by getting consumers and locking them into their unicorns and rainbows ecosystem where everything is perfect which makes consumers comfortable spending boat loads of money, not by selling commodity hardware.
Ecosystems with great UX and paid subscriptions plus a 30% cut on all transactions are far more profitable than the margins you make selling commodity hardware. Just ask famous phone manufacturers like Siemens, Nokia and Blackberry why that is. That's why SW dev salaries are much higher than HW dev salaries as the former generates way more revenue than the latter. That's why Apple doesn't roll out their own cloud datacenters and instead just gets Amazon, Microsoft and Google to compete against each other on pricing.
Apple only rolls out their solutions when they have an impact on the final UX, like designing their own M1 silicon.
And number two, selling chips comes with a lot of hassle like providing support to your partners like Intel and AMD do. Pretty sure they don't want to bother with that.
Before they start selling chips I would rather they open iMessage to other platforms to eliminate the bubble color discrimination.
Ecosystems with great UX and paid subscriptions plus a 30% cut on all transactions are far more profitable than the margins you make selling commodity hardware. Just ask famous phone manufacturers like Siemens, Nokia and Blackberry why that is. That's why SW dev salaries are much higher than HW dev salaries as the former generates way more revenue than the latter. That's why Apple doesn't roll out their own cloud datacenters and instead just gets Amazon, Microsoft and Google to compete against each other on pricing.
Apple only rolls out their solutions when they have an impact on the final UX, like designing their own M1 silicon.
And number two, selling chips comes with a lot of hassle like providing support to your partners like Intel and AMD do. Pretty sure they don't want to bother with that.
Before they start selling chips I would rather they open iMessage to other platforms to eliminate the bubble color discrimination.
> Before they start selling chips I would rather they open iMessage to other platforms to eliminate the bubble color discrimination.
Outside of the countries where iOS is on par with Android (I think US, Canada and UK are the only ones, maybe also Australia) in terms of popularity, I don't know or have seen a single person using iMessage, of course there's a lot people using iphone outside of the mentioned countries, but absolutely nobody uses iMessage.
The whole discrimination of the color bubble seems to only happen in those countries were iOS is the same or more popular than android and people is actually using iMessage.
Outside of the countries where iOS is on par with Android (I think US, Canada and UK are the only ones, maybe also Australia) in terms of popularity, I don't know or have seen a single person using iMessage, of course there's a lot people using iphone outside of the mentioned countries, but absolutely nobody uses iMessage.
The whole discrimination of the color bubble seems to only happen in those countries were iOS is the same or more popular than android and people is actually using iMessage.
It's worse than that in the US. While iOS is a bit over 50%, it's closing in on 90% for teens[0], where such discrimination is most likely to occur. These numbers also bode well for Apple's future market share as these teens grow into adults.
0: https://finance.yahoo.com/news/apple-i-phone-ownership-among...
0: https://finance.yahoo.com/news/apple-i-phone-ownership-among...
It's getting similar in Europe for teens. I rarely see them on public transport with anything other than an iPhone.
Go to southern countries or eastern Europe, plenty of teens with Android.
In Russia, people stopped sending each other SMS before smartphones even became mainstream. At the time they were becoming mainstream, ICQ was the instant messaging service to use, and of course there was an unofficial ICQ client for just about anything that had a screen, a keyboard, and a network interface. Also VKontakte, but that was easily accessible via Opera Mini.
Right now 99.9% of those Russians who use the internet can be reached via either VKontakte or Telegram. WhatsApp is also popular, but thankfully not around me so I was able to delete my account and never look back.
Right now 99.9% of those Russians who use the internet can be reached via either VKontakte or Telegram. WhatsApp is also popular, but thankfully not around me so I was able to delete my account and never look back.
> but absolutely nobody uses iMessage
Uhm, iMessage works transparently. I just use Messages app, if my recipient uses iPhone it get an iMessage, if they use something else, they get SMS.
Uhm, iMessage works transparently. I just use Messages app, if my recipient uses iPhone it get an iMessage, if they use something else, they get SMS.
Their point is that most people don’t use the Messages app to communicate with others. In the UK for example WhatsApp is massively dominant.
Ditto. I'm the leper who prefers to not use whatsapp and only get away with it since my partner takes up the slack, so to speak.. Last weekend she and i where bemused by the inability of our 100% APPLE hosts to: 1. Use airprint (worked from my linux phone!!!) 2. Share a file with linux or android (mp3 for a ringtone) 3. Install a ringtone. Breathtaking. I still have my classic. And si. I have more proprietary apple software on diskettes than most geeks I know. But apple tanked long ago. And hardware is cheap. And foss is fun.
I see people using iMessage in a country where iPhone has a whopping 7% market share. And yes,
> Before they start selling chips I would rather they open iMessage to other platforms to eliminate the bubble color discrimination
It’s probably easier to just move to one of the 99% of countries where nobody uses iMessage.
It’s probably easier to just move to one of the 99% of countries where nobody uses iMessage.
I already do, in Europe, where everyone and their mom uses Facebook's WhatsApp for everything. While that evens the playing field, I'm not sure I'd call trading a walled garden for a spyware one a massive victory though.
So who cares that a network nobody uses exists where only people that have an Apple device can login?
Apparently teens and even some adults in the US where they'll miss out on social activities or be mocked or ignored due to not being on iMessage.
That doesn't affect me though as i don't live in the US and am too old for that kind of stuff but I do remember how easy it was to be mocked or bullied as a teen for not having the same stuff as the herd, even before smartphones were a thing.
That doesn't affect me though as i don't live in the US and am too old for that kind of stuff but I do remember how easy it was to be mocked or bullied as a teen for not having the same stuff as the herd, even before smartphones were a thing.
How do you know if this is really a thing and not just some dramatic story of the week in the media?
I agree with you right up to how exactly does the M1 chip affect the final UX? A different keyboard, screen, touchpad, etc. all make a difference but why does the chip make a difference?
>how exactly does the M1 chip affect the final UX?
Everything runs faster, cooler, quieter and battery lasts longer. Is that not part of the product UX?
Everything runs faster, cooler, quieter and battery lasts longer. Is that not part of the product UX?
That makes it sound like Intel, AMD, ARM, etc. we’re trying to build chips that run hotter and less efficiently.
Not really
They are trying to compete, and have different levers to pull with varying success. When the performance per clock or per watt levers don't work well enough, then they increase the power, and the end result is heat and inefficiency.
On the flip side, integrated solutions add another lever... writing hardware that does exactly what your software needs to improve the user experience.
AMD, ARM, and even Intel have some cool, efficient solutions, but not across their whole portfolio of products, and not at the higher ends of performance. But they are always competing, incrementing and working to get closer to that ideal.
Apple was able to focus on their exact market segment and get there rapidly.
They are trying to compete, and have different levers to pull with varying success. When the performance per clock or per watt levers don't work well enough, then they increase the power, and the end result is heat and inefficiency.
On the flip side, integrated solutions add another lever... writing hardware that does exactly what your software needs to improve the user experience.
AMD, ARM, and even Intel have some cool, efficient solutions, but not across their whole portfolio of products, and not at the higher ends of performance. But they are always competing, incrementing and working to get closer to that ideal.
Apple was able to focus on their exact market segment and get there rapidly.
The end users don't care what brand of chip is under the hood, or why the UX on Apple's implementation of Intel chips sucked, they just know the new device has much better UX overall due to the more powerful and more efficient chip and will upgrade for that.
Seems like Intel really lost the plan there with every new generation having just a few percent better performance, trouble with moving to smaller nodes and the enormous regression from spectre/meltdown.
The Apple chips are made for running macOS/iOS. Seems there are some hardware instructions that are tailor made for increasing the performance of Apple software so they can make sure everything is working toward a common goal.
The Apple chips are made for running macOS/iOS. Seems there are some hardware instructions that are tailor made for increasing the performance of Apple software so they can make sure everything is working toward a common goal.
> I agree with you right up to how exactly does the M1 chip affect the final UX?
It allows apple to focus on what they want without being limited by and two their hardware provider’s strategy.
It allows apple to focus on what they want without being limited by and two their hardware provider’s strategy.
Power efficiency for one.
Was there nobody else who made power efficient chips?
Many other manufacturers had made power-efficient ARM chips, however, the mainstream computer makers (just a few years ago including Apple) did choose x86 compatibility over power efficiency.
None of the other CPU manufacturers have access to the same silicon Apple does, so it's hard to say.
That would make sense in the context of Intel but anyone with money has access to TSMC 5nm (in 2021-2022). Do I misunderstand?
Just because you have money doesn't mean you have a market. Just to run a plate to create test cpus cost in the millions. All others were happy with the incremental upgrades that they were getting from ARM. Apple needed more and started creating CPUs for the iPhones a few years back
Looks like I did misunderstand, I thought they actually meant the silicon technology itself which is now available to the others and they all have designs coming using it.
Not in the x86 arena. Every time Apple gets involved with a CPU developers (Motorola, IBM, Intel) their needs splits from the developers desires. This time they decided to go on their own (well after years of doing this for the iPhone). Note: They have been involved in the ARM CPU market since the days of the Newton.
> Before they start selling chips I would rather they open iMessage to other platforms to eliminate the bubble color discrimination.
When so many telcos charge outrageous prices for SMSs, it's a useful feature.
When so many telcos charge outrageous prices for SMSs, it's a useful feature.
Or alternately one where some Windows / Linux manufacturer could match Apple for all the innovations in the M1 Macbooks. I'm not an Apple fan but I'm envious of what they've accomplished and wish I could run Windows and Linux on similar hardware.
Other folks are starting to get there but only from the mobile device direction, e.g. Tensor. Maybe I should look closer at what Microsoft has done with ARM Surface.
Other folks are starting to get there but only from the mobile device direction, e.g. Tensor. Maybe I should look closer at what Microsoft has done with ARM Surface.
It doesn't help that Apple bought the entire manufacturing capacity for 5nm silicon from TSCM right before the chip shortage hit. I think the next few years are going to get very competitive though, and I'm excited to see how Intel and AMD respond.
Apple has done that before. IIRC when the original iPod came out it used a new generation of HDD. Apple went to the drive manufacturer and said "we'll take all of them" and they agreed.
How is Amazon able to product their arm chips for aws? Assuming those are not the 5nm?
There's still 5nm silicon for sale, but just not at TSCM (the largest semiconductor manufacturer in the world). Companies like Samsung are just now getting around to mass-producing 5nm, and afaik there were a few domestic Chinese manufacturers who claimed to be on the node too.
As for Amazon specifically though, I've got no idea. They're a large enough company that they could buy out an entire fab or foundry if they wanted, AWS makes more than enough money to cover the costs.
As for Amazon specifically though, I've got no idea. They're a large enough company that they could buy out an entire fab or foundry if they wanted, AWS makes more than enough money to cover the costs.
Nitpick: it's TSMC, Taiwan Semiconductor Manufacturing Company.
> all the innovations in the M1 Macbooks
What are the innovations in them? From everything I've heard, they just basically reverted all the changes most people hated for the last few years and slapped a new chip in there.
What are the innovations in them? From everything I've heard, they just basically reverted all the changes most people hated for the last few years and slapped a new chip in there.
The "walled garden" comes with a C and C++ toolchain, python, perl, awk, sed, and a Unix shell. It is not, in any way, a "walled garden" in a universe where words have shared meaning.
Exactly, I cannot believe the Hacker News crowd are penalising you for correcting OP on not knowing that the walled garden metaphor specifically refers to the App Store, which is not an issue on MacOS.
No. That might have been where you first saw the concept applied, but a walled garden is a commercial ecosystem that is deliberately closed to foster a sense of value and exclusivity, usually in spite of no technical reason for it.
Walled gardens are inherently anti consumer market plays that make things worse for everyone except the people milking money from the idiots paying into the walled garden.
Walled gardens are inherently anti consumer market plays that make things worse for everyone except the people milking money from the idiots paying into the walled garden.
What part of MacOS is a walled garden? I can use any Bluetooth or USB device with it. I can install Linux on it. I can compile my own code on it. I can download applications from any source I please and install them.
I agree but would distinguish the mac from the phone? Bluetooth file transfers are a wall problem with ios. Assume you mean macosx?
The Pi has much better performance per dollar, which is a metric that's important to some people too.
They won't. Their margins on the services side are obscene so getting people into that ecosystem is worth much more than the sales of some processors.
I'm hoping Alyssa Rosenzweig's fantastic work documenting the M1 GPU will let us write native Vulkan drivers even for MacOS. I believe she's been focusing thus far on the user space visible interfaces, so a lot of that work should translate well.
I'm sure there's a not so distant future where Broadcom ships a 7nm (or smaller) SoC that finds its way into the Raspberry Pi series.
It's not like Apple has a meaningful moat around state of the art silicon. And that's a Good Thing.
It's not like Apple has a meaningful moat around state of the art silicon. And that's a Good Thing.
Also accepted would be a world where they just add Vulkan support to their APUs already.
A fully compliant Vulkan implementation for M1 would come with very surprising performance cliffs for a developer.
One of them: https://github.com/KhronosGroup/MoltenVK/issues/1244
One of them: https://github.com/KhronosGroup/MoltenVK/issues/1244
And also potential optimisations that are not possible in other GPUs:
https://developer.apple.com/documentation/metal/gpu_features...
https://developer.apple.com/documentation/metal/gpu_features...
That's pretty common for TBDRs. The tile is rendered into a fixed size on chip buffer, and the driver has to split the tile into multiple passes to fit all of the render target data for nutty amounts of data coming out of the shader. PowerVR works the same way (completely unsurprisingly).
See this comment on that issue: https://github.com/KhronosGroup/MoltenVK/issues/1244#issueco...
It'd be surprising if an architecture had 0 such surprises and did everything Vulkan allows without any special performance considerations vs another architecture.
How about MoltenVK?
https://github.com/KhronosGroup/MoltenVK
https://github.com/KhronosGroup/MoltenVK
It's fine, but it's frankly silly that you're forced to translate a free and open graphics API into a more proprietary one. Compare that to something like DXVK, which exists because Linux users cannot license DirectX on their systems. MoltenVK exists simply because Apple thought "let's not adopt the industry-wide standard for CG graphics on our newer machines". Again, not bad, but a bit of a sticky situation that is entirely predicated by technology politics, not what's actually possible on these GPUs.
Metal was released a year before Vulkan. Apple just didn't want to wait and decided to design their own better than OpenGL API.
DirectX was released a decade before Vulkan, that didn't stop manufacturers from including support for both so the user could decide for themselves.
You mean the support that is only possible because Windows backward compatibility still supports the OpenGL 1.1 ICD that they rely on?
Most of the time with crappy drivers that are a shadow of their DirectX ones?
Most of the time with crappy drivers that are a shadow of their DirectX ones?
> still supports the OpenGL 1.1 ICD that they rely on?
On Windows 11, it’s OpenGL 3.3 on top of DX12, because Qualcomm doesn’t provide an OpenGL ICD at all.
> crappy drivers
Special mention to the Intel OpenGL graphics driver on Windows. If you thought that the AMD Windows one was bad, the Intel one was somehow significantly worse.
On Windows 11, it’s OpenGL 3.3 on top of DX12, because Qualcomm doesn’t provide an OpenGL ICD at all.
> crappy drivers
Special mention to the Intel OpenGL graphics driver on Windows. If you thought that the AMD Windows one was bad, the Intel one was somehow significantly worse.
With this gpu performance you’d think Apple might like to take advantage for gaming.
They already do, all middleware engines that actually matter, already support Metal.
Additionally iOS and Apple have much better tooling for Metal than plain DirectXTK/Pix, or that toy SDK from Khronos (that Google also uses on Android), if we compare vendor tooling.
Additionally iOS and Apple have much better tooling for Metal than plain DirectXTK/Pix, or that toy SDK from Khronos (that Google also uses on Android), if we compare vendor tooling.
Sounds like you don't need any help then, enjoy your 50-75% performance hit playing (a scant few) games through DirectX -> Vulkan -> Wine/Crossover ($30) -> MoltenVK -> Metal!
The games I care about enjoy native Metal and DirectX, and when I code anything graphics I don't use Khronos stuff, only on the Web, where there is no other option.
Any game dev gems have basic examples on doing an API loading layer.
Vulkan is mostly a Linux thing, and even the Switch has its own native API, NVN, it is not Vulkan nor OpenGL on the driving seat.
Here enjoy, https://www.ogre3d.org/
Any game dev gems have basic examples on doing an API loading layer.
Vulkan is mostly a Linux thing, and even the Switch has its own native API, NVN, it is not Vulkan nor OpenGL on the driving seat.
Here enjoy, https://www.ogre3d.org/
That’s not shown in terms of games people actually want to buy.
> It's fine, but it's frankly silly that you're forced to translate a free and open graphics API into a more proprietary one.
Thats exactly what every graphics API has done, because the underlying chip architecture is never free and open (and often, is neither).
If the issue is that you are targeting a proprietary intermediate API rather than bare metal, that is also how Nvidia's drivers work.
Thats exactly what every graphics API has done, because the underlying chip architecture is never free and open (and often, is neither).
If the issue is that you are targeting a proprietary intermediate API rather than bare metal, that is also how Nvidia's drivers work.
Is what is possible with Metal possible with GL though? Both in performance and features? They didn’t build Metal just to be contrarian.
Why? Apple has always stated they don't want to be in an enterprise like market. It stifles innovation. While you can keeps adding features to your product you can never take away from it. Ex: x86 and Windows. Meanwhile Apple has removed entire CPU functionality from their chips since the release of the iPhone 4S. This was easy because they only had to deal with their own developers. This keeps them agile and able to change from 1 release to another.
That's a bit of an ironic comment
Broadcom chips are not available on the open market and they won't sell to you unless you are an enormous company(or have a "special relationship" as RPi did). Effectively you can only buy one attached to a Pi.
Broadcom chips are not available on the open market and they won't sell to you unless you are an enormous company(or have a "special relationship" as RPi did). Effectively you can only buy one attached to a Pi.
Maybe they could make their own SBC, just an M1 and four USB-C ports… Apple Pi?
Why? They gave "it's possible" proof. They rip benefits of doing it first - all good. Now it's time for competition to pick it up, possibly improve on it or fade away Intel style.
No worries. Competition is coming.
https://www.phoronix.com/scan.php?page=news_item&px=SiFive-P...
Should be roughly M1 performance, but on RISC-V.
https://www.phoronix.com/scan.php?page=news_item&px=SiFive-P...
Should be roughly M1 performance, but on RISC-V.
uffff
who knows when that is coming and when are we going to be able to buy regular laptops from e.g. Lenovo, HP, Acer, etc with that.
By the time that happens, Apple may already be on their third, fourth? generation on M1. Which is going to much much much faster than M1.
who knows when that is coming and when are we going to be able to buy regular laptops from e.g. Lenovo, HP, Acer, etc with that.
By the time that happens, Apple may already be on their third, fourth? generation on M1. Which is going to much much much faster than M1.
>Which is going to much much much faster than M1.
Will it really?
It isn't a given. They might bring amazing progress, or not.
Ultimately, it doesn't matter all that much if it isn't available to third parties. It's not as if everybody else is sitting on their ass.
SiFive's not a fat company, their research budget is tiny, relative to the likes of Apple. And yet, they're coming up with competitive cores.
Things are so much easier when not restricted by a shitty ISA (x86). I have taken a look, and I really like RISC-V; I find it better than ARM.
Will it really?
It isn't a given. They might bring amazing progress, or not.
Ultimately, it doesn't matter all that much if it isn't available to third parties. It's not as if everybody else is sitting on their ass.
SiFive's not a fat company, their research budget is tiny, relative to the likes of Apple. And yet, they're coming up with competitive cores.
Things are so much easier when not restricted by a shitty ISA (x86). I have taken a look, and I really like RISC-V; I find it better than ARM.
M1 is WAY faster than a cortex A78.
Congrats! Huge effort. Full spec of Broadcomm GPU (24 GFLOPS)
https://forums.raspberrypi.com/viewtopic.php?t=244519
https://forums.raspberrypi.com/viewtopic.php?t=244519
I guess this means you can use Kompute (kompute.cc) on RPi 4, now?
(A GPGPU framework, to save others a click.)
Except not a framework, it's just a library. You can use it to do any of the stuff you would do with CUDA, about as fast, but portably. #include it to accelerate your game's physics engine, or whatever.
It doesn't say so at kompute.cc, but I found that it depends on Vulkan 1.1.
It doesn't say so at kompute.cc, but I found that it depends on Vulkan 1.1.
I wonder if we'll see any impacts from this on the Pi 4 applications that are presently borderline when it comes to performance, like N64 emulation.
What’s the test software / benchmark I should use on Linux nowadays to measure (and compare) shader and raw GPU performance? That would ideally run under both X and Wayland?
I have always tended towards Phoronixs test suite (https://www.phoronix-test-suite.com/) but Im sure there are a few specific to Vulkan around. Not sure about wayland.
The application(s) you want to run is the best benchmark.
Problem with this is that the application I have in mind doesn't provide anything but perceptual feedback. I'd rather have some cold numbers that are to some degree reproducible and would give at least rough idea of the performance of given HW+drivers+other-settings combination.
Maybe the mesa fps overlays (no app modification needed) described here can help? https://gazoche.xyz/fps-overlays-on-linux.html
Thank You! That, and especially MangoHUD which that page links to look really promising. Thank You again!
I wonder if a Raspberry GPU board (low cost graphics performance) is possible. For light Blender work and maybe simple games.
It’s better even in GPU perf/$ to buy a Jetson Nano 2GB, the RPi4 GPU is really small (and not that well featured).
FP32 GFLOPS, ballparks from random sources:
- this: 24
- Ryzen 5600g: 200(CPU)
- Jetson nano: 235
- GeForce GT1030: 1127
- Ryzen 3rd IGP: 2100
- Apple M1X: 5200
- Apple M1 Pro: 10400
- RTX3080: 35580
1030 can be had for $110 even at this height of GPU shortages, not that much more than a Nano. hmm
- this: 24
- Ryzen 5600g: 200(CPU)
- Jetson nano: 235
- GeForce GT1030: 1127
- Ryzen 3rd IGP: 2100
- Apple M1X: 5200
- Apple M1 Pro: 10400
- RTX3080: 35580
1030 can be had for $110 even at this height of GPU shortages, not that much more than a Nano. hmm
But a GT1030 can’t be hooked up to a small board like Raspberry or even the Nano, right?
You can hook up a desktop graphics card to Raspberry Pi 4 compute board. It's got 2 lanes of PCIe gen 2.
Its very unlikely you can get drivers working with it though.
That’s a shame!
But you can only run one flavor of Linux on it, since NVidia keeps the specs closed.
Today on the Jetson Nanos, you can just use the Fedora stock image. (flashed to a microSD card)
It’s much better than what it was before. nouveau works ootb, including reclocking too.
It’s also to be noted that all Tegras have an open-source kernel mode GPU driver (nvgpu) even when using the proprietary stack. However, that driver isn’t in an ideal state today.
It’s much better than what it was before. nouveau works ootb, including reclocking too.
It’s also to be noted that all Tegras have an open-source kernel mode GPU driver (nvgpu) even when using the proprietary stack. However, that driver isn’t in an ideal state today.
Can you use stock Ubuntu?
The one nvidia provides is not stock.
The one nvidia provides is not stock.
The Jetson Nano uses a very similar SoC to the Nintendo Switch, so you can expect similar performance.
It uses half a switch SoC GPU wise
All versions? Would be cool to use a hacked switch running linux instead of Jetson if the performance was that much better.
921.6MHz is the GPU clock on Jetson Nano (at MAXN).
For the Switch:
> The GPU cores are clocked at 768 MHz when the device is docked, and in handheld mode, fluctuating between the following speeds: 307.2 MHz, 384 MHz, and 460 MHz
For the Switch:
> The GPU cores are clocked at 768 MHz when the device is docked, and in handheld mode, fluctuating between the following speeds: 307.2 MHz, 384 MHz, and 460 MHz
Wow that’s an interesting device! Thanks!
Now combine this with Zink and boom! We get OpenGL 4.6 for free: https://www.phoronix.com/scan.php?page=news_item&px=Zink-Clo... .
Vulkan is too low level, but AFAICS it is not something one use directly, instead a library which uses it as a back-end should be used.
Vulkan is too low level, but AFAICS it is not something one use directly, instead a library which uses it as a back-end should be used.
> Now combine this with Zink and boom! We get OpenGL 4.6 for free
For the RPi4 specifically:
That GPU has hardware limitations that make it unable of OpenGL 3.0. However, it supports GLES 3.2.
If you want GL desktop minus the unsupported features by the hardware, you can set MESA_GL_VERSION_OVERRIDE=3.3 for example. That will however never be compliant.
Vulkan has many extensions to allow it to work on hardware which doesn’t support the full feature set. (by not implementing them, instead of having only version numbers)
For the RPi4 specifically:
That GPU has hardware limitations that make it unable of OpenGL 3.0. However, it supports GLES 3.2.
If you want GL desktop minus the unsupported features by the hardware, you can set MESA_GL_VERSION_OVERRIDE=3.3 for example. That will however never be compliant.
Vulkan has many extensions to allow it to work on hardware which doesn’t support the full feature set. (by not implementing them, instead of having only version numbers)
The Pi hardware may not support multiple render targets or other features in hardware directly but Zink is not required to (and does not always) emit 1 Vulkan API call for each OpenGL API call. It is free to issue as many as are needed to properly emulate the OpenGL API in a conformant way. That being said I don't think this particularly compatibility is in Zink today but there is nothing preventing it from being possible just because the hardware couldn't create the render targets all in one shot.
> but Zink is not required to (and does not always) emit 1 Vulkan API call for each OpenGL API call
The OpenGL driver also doesn't have to emit 1 logical hardware operation for each OpenGL API call.
The OpenGL driver also doesn't have to emit 1 logical hardware operation for each OpenGL API call.
There is no hard technical requirement for hardware drivers but it's riskier to expose performance impacting emulation at that level vs the layered driver level (where Zink is). For instance imagine a case where the hardware supported 4 MRTs but the hardware driver emulation layer exposed 8 MRTs for OpenGL compatibility yet Zink needed to use 16 MRTs. Now you've got all sorts of translation happening where Zink is likely calling the lower emulation layer multiple times rather than just calling the hardware directly. Such emulation layers are expected in a layered driver, that's part of their actual intent, whereas base hardware drivers are meant to expose what the hardware is able to do natively and let you work around it otherwise.
You can already enjoy stuff like OpenGL 2.1 support on purely GLES 2.0 hardware this way - for instance on older Raspberry Pis. There's not much Zink will bring on the table that Gallium doesn't already when it comes to emulation of missing hardware features (at least not if you want them to actually perform in any reasonable way).
Ideally, shouldn't zink query the vulkan driver for what capabilities the hw has, and then expose an appropriate OpenGL version?
Unconditionally exposing the latest GL version by emulating missing GPU functionality sounds like a recipe for applications to fall off performance cliffs.
Unconditionally exposing the latest GL version by emulating missing GPU functionality sounds like a recipe for applications to fall off performance cliffs.
I wonder what specifically the GPU missing that OpenGL needs.
The OpenGL 3.0 spec mandates support for 8 render targets, the RPi4 GPU only has support for 4.
I've always wondered how this would work. Surely if it was possible to reasonably implement OpenGL 4.6 on the PI GPU it would already be done through Mesa.
This is great for many reasons.
https://www.reddit.com/r/MachineLearning/comments/ilcw2f/p_v...
https://www.reddit.com/r/MachineLearning/comments/ilcw2f/p_v...
This is raspberrypi OS only right? Aren't the normal linux drivers still broken for 3d?
No and no. "driver changes for Vulkan 1.1 conformance have already been merged in the upstream v3dv Mesa driver"
in TFA: s/Iglia/Igalia/
ugh, now if I could only buy a few haha
What for? I'm sure you have some older computers that run much better that you already have in your house. An APU would trounce it. Pi feel like netbooks of desktop computers, the new ones get extremely hot, I would expect it to require a heavy heatsink and constantly spinning fan if you tried this.
Better power efficiency
Could we see a portable Epic Games console, pugged directly into their store?
Like the Steam Deck, but better, since developers will get 88% of revenue instead of 65% on Steam.
Like the Steam Deck, but better, since developers will get 88% of revenue instead of 65% on Steam.
The Steam Deck is a generic PC. It's not locked to the Steam store. It's not even locked to the OS it comes with. You can install the Epic store, or any other store, on it right now. If you have one, anyway.
You can download EGS games on Linux just fine, so ostensibly you could build one of these right now. Of course, you probably wouldn't want to use ARM for a PC game console, but you're welcome to try it.
*slurp*
If you focused on supporting the official raspberry pi keyboard, mouse, and touchscreen you could circumvent a lot of the pains around driver issues. Then people could actually get up and running with your OS with real hardware, and you could start dogfooding it.
I’ve heard people say that the software we use is up to 100 times slower than it needs to be. So my hypothesis is that if the software was written smarter, and used the fact that we know the hardware ahead of time, we should easily hit a 100 times performance increase across the OS.
Also if it were possible, it would be cool if this OS supported a minimal boot mode, that could be configured to only run the bare minimum amount of apps required for a certain piece of software. So for example a game mode that ran the game, and the bare minimum amount of OS the game needed to run.
And since we are in full on fantasy land we can take this one step further. Same basic concept, but with a RISC-V SBC, with an open GPU. Bonus points if you can get up and running with a touchscreen, keyboard, mouse, case, and SD card for $150