The amount of editorial in this post is mind blowing. Am I the only one who found it extremely hard (yes, extremely) to sift through all the blurb of text. In the end, I am not even sure what is being released.
The new configuration system in Qt, allows your define the content you need from each module in much more detail for your project and easily allows for feature based tailoring of the Qt modules. We are starting with enabling this fully for Qt Core, Qt Network, Qt GUI, Qt QML and Qt Quick. You can now fine tune which features from these modules you want to include in your project. There is no longer any need to include unnecessary features.
To be clear, this potentially reduces binary sizes, but it does not by itself change run-time performance.
No Open GL Requirement ... The Qt Quick 2D renderer can work in software only, but it is also designed to utilize accelerated 2D operations, for devices that packs a little bit more punch, but still doesn’t have full OpenGL support.
I wonder what kinds of devices this is intended for? Presumably, they are a very important market for Qt to have implemented this? And these devices have graphics displays but they lack GPUs? What device could that be?
CPU software rendering seems like a step backwards for performance. GPUs and OpenGL must be more energy efficient at this task than software rendering, and I would imagine that important embedded devices with graphics displays must all have GPUs or will in the future?
I would have thought that "Qt for any platform" would include web browser (WebAssembly / Emscripten / WebGL) but no such luck. Based on the title, I thought this was going to be some drastic optimization of Qt's GUI. It doesn't sound like that's the case.
I haven't used Qt on embedded devices, but I've looked at several demos of Qt compiled to JavaScript with Emscripten [1] and the results seem very slow. Part of the reason seems to be that these Emscripten demos have Qt falling back to software rendering, instead of using WebGL accelerated rendering ... I don't think that another software rendering backend for Qt solves this problem.
I wonder what kinds of devices this is intended for?
This: http://www.st.com/content/st_com/en/products/evaluation-tool... ARM Cortex M-4 architecture, 800 x 480 full color display, 16MB of RAM and 16MB of flash on this demo board and the part includes a 2D bitblit unit (ST calls is ChromArt(tm)) which can do fill from constant, memory to memory region copy, memory to memory copy with alpha blend, (and all three with pixel format conversion options)
Put a keyboard and a VGA monitor on it and you've got a PC that is at least as powerful as the ones from the late 80's early 90's.
Off the top of my head, with no experience in this field, appliance displays? E.g. a screen on your fridge. Or even the screen in your car? Touch interfaces of roughly this size are popping up everywhere.
Certainly, why would you want that vs. a $5 Rapsberry Pi Zero which does have an actual GPU, media acceleration, etc., more RAM, a more powerful CPU, etc.
E.g. because of much longer guaranteed support/supply life, which is a must if you are trying to run a serious production. There might be some other reasons too.
> because of much longer guaranteed support/supply life
The underlying components in the Pi Zero also have a long "guaranteed" support/supply life. You don't have to rely on the Pi foundation for your components, or the board itself (as I pointed out in another reply in this thread).
My primary point is that the cost of a GPU these days is very close to zero, so I see little benefit in picking a platform that doesn't have one if you need that capability.
Uhhh have you ever dealt with Broadcom? The BCM2835 chip powering the RPi zero isn't something you can buy without negotiating with Broadcom directly and a minimum order size in the tens or hundreds of thousands. That is a far cry from STM parts you can order off of Digikey or Mouser. Even some of my bigger clients won't base products on Broadcom chips for that reason alone.
And no, even in the best of cases where you have great software support from the vendor (ha! as if) and a great reference design, adding a GPU to a design is expensive because of both software and hardware R&D. unless you have an integrated CPU/GPU combo but then you're back to the problem of dealing with Qualcomm/Broadcom.
Raspberry Pi Zero's seem to be hanging out with Sasquatch and Nessie these days.. that is, if they really exist at all and aren't just one of those myths, like the one about Elon Musk being an actual human.
The main thing that is usually overlooked is that Raspberry Pi is a charity and they do not make commercial products with the intent to make money from it.
Well okay, why would you make the choice to go with something like the STM32F4 ARM Cortext-M processor vs something like the Raspberry PI with an ARM Cortex-A series processor? Well I'm glad you asked.
First you need to ask, what does your device need? Some things to consider:
- Power consumption
- Real time sensors or I/O
- Safety critical
- Processing / Computing power
- Image / Video processing
- < 10" display
- > 10" display
- etc
All of these are at the beginning of making a choice of which processor series you want to use.
But, wait if an Cortex-A Series can be sold for $5 why don't I just got with an Cortex-A series, because, well they aren't. See my first sentence and now my following.
If you compare the higher-end M4/M7 processors from ST (STM32F4xx / STM32F7xx with Chrom-ART / DMA2D Support) vs something like the NXP/Freescale A9 single core (i.MX6Solo) at quantity 1,000, you're looking at between $7-$10 for the Cortex-M4 and $13-$15 for a Cortext-A9.
Okay, so they aren't that much different in price (depending on who you are and how much the rest of your system costs). So, you need to then compare it even further. Typically on a Cortex-M Series you are looking at an RTOS, whereas on a Cortex-A series you are looking at a real OS (Linux, Android, Windows, etc). Why does this matter? This has to do with hardware support and the core difference between an RTOS and an OS. If your board processor, peripherals, etc are not well supported or you are doing a custom pcb design, you are going to be writing your own drivers which equates to NRE (Non-recurring Engineering), which can be expensive. This cost could be consumed by the company as a business expense or be captured back into the cost of the device. Then you have tool chains, support, and familiarity, and so on.
So, if the above did it's job, that might have helped into understanding why you may or may not go with a Cortex-M or Cortex-A series. And yes you may be right on the edge of going with one or the other.
Automotive In-Vehicle-Infotainment (IVI) systems that feature embedded SoCs running Linux for the GUI on an MPU and embedded RTOSs on MCUs for some of the more real-time/routine functions. Energy efficiency is secondary to the unnecessary cost/performance profile of building in a GPU to render relatively simple dashboard graphics.
The automotive market is the fastest-growing (and one of the largest) vertical markets for embedded MCU/MPUs, and by extension, embedded software.
It's not my area, but I have a hard time believing that any competitive, modern IVI would be missing GPU integration. Just looking briefly, both Qualcomm [1] and NVIDIA [2] automotive systems have on-board GPUs.
And the price difference between a device that didn't have gpu compared to those that don't will just shrink over time so any margin you might get yesterday will not be what you can get in the future.
"GPUs and OpenGL must be more energy efficient at this task than software rendering, and I would imagine that important embedded devices with graphics displays must all have GPUs or will in the future?"
Adding to what was said in other comments, another problem is graphic drivers that mostly come as binary blobs and no source code available. Many projects, especially missions critical ones, avoid having uninspected binary blobs in their systems.
"And these devices have graphics displays but they lack GPUs? What device could that be?"
I've deployed Qt HMI projects on Cortex-M3/M4 devices like the NXP LPC1788/4088, and GPU-less A9 cores like the Renesas RZ/A1L. I've even done one on a wacky Chinese MIPS core.
They all use a raster framebuffer + LCD controller. Works just fine for a hell of a lot of things. I have yet to do a HMI project in Qt Quick, nor do I plan to in the future.
> I wonder what kinds of devices this is intended for? Presumably, they are a very important market for Qt to have implemented this? And these devices have graphics displays but they lack GPUs? What device could that be?
Unfortunately many (mostly Intel) chipsets have terrible drivers and have been blacklisted in Qt 4.6. So if you want to target a large share of all desktop machines the software renderer is a must.
I'm thinking about avoiding it for my IoT device node work.
I'm prototyping a node project right now for a large customer (>50K deployments) and while Qt helped me get code running quickly there won't be a way to comply with the dynamic linking model on my final hardware. Can't afford the Qt license in my BOM (probably would be 25% of my bill) so out it goes.
