6 ms·
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
by n00b101 10y ago
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.
[1] http://vps2.etotheipiplusone.com:30176/redmine/projects/emscripten-qt/wiki/Demos http://vps2.etotheipiplusone.com:30176/redmine/projects/emsc...
- roymurdock 10y agoAutomotive 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.
- n00b101 10y agoIt'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. [1] https://www.qualcomm.com/products/automotive/infotainment https://www.qualcomm.com/products/automotive/infotainment [2] http://www.nvidia.ca/object/drive-cx.html http://www.nvidia.ca/object/drive-cx.html
- roymurdock 10y agoCheck out Freescale and Renesas solutions. They are major automotive SoC players. The Renesas R-Car platform does integrate a dual-core Power-VR GPU: https://cache.freescale.com/files/32bit/doc/fact_sheet/IMX6SRSFS.pdf https://cache.freescale.com/files/32bit/doc/fact_sheet/IMX6S... https://www.renesas.com/en-us/solutions/automotive/products/rcar-h1.html https://www.renesas.com/en-us/solutions/automotive/products/...
- icefox 10y agoAnd 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.
- nullcipher 10y agoSame here. It would be very poor long term investment to put a chip into a car without a GPU. But, I think the Qt changes are for IoT and not for cars.
- ChuckMcM 10y agoI wonder what kinds of devices this is intended for? This: http://www.st.com/content/st_com/en/products/evaluation-tools/product-evaluation-tools/mcu-eval-tools/stm32-mcu-eval-tools/stm32-mcu-discovery-kits/32f469idiscovery.html 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.
- roymurdock 10y agoWhat are possible use cases for a device like this? (I didn't downvote you and I don't know why anyone would)
- ChuckMcM 10y agoAnything that needs a rich graphical interface and a simple programming model? I've seen these things in things like digital signs, kiosks, etc.
- erichocean 10y agoCertainly, 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.
- anmorgan 10y agoThe 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. ( http://www.digikey.com/product-search/en/integrated-circuits-ics/embedded-microcontrollers/2556109?k=stm32f429 http://www.digikey.com/product-search/en/integrated-circuits... ) ( http://www.nxp.com/products/microcontrollers-and-processors/arm-processors/i.mx-applications-processors/i.mx-6-processors/i.mx6qp/i.mx-6solo-processors-single-core-multimedia-3d-graphics-arm-cortex-a9-core:i.MX6S?&cof=0&am=0&tab=Buy_Parametric_Tab&fromSearch=false http://www.nxp.com/products/microcontrollers-and-processors/... ) 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.
- jotux 10y ago>I wonder what kinds of devices this is intended for? I worked on POS terminals that were 400MHz ARM11 with no GPU. We were using Qt in a proprietary OS to do little touchscreen UIs.
- otabdeveloper 10y ago> CPU software rendering seems like a step backwards for performance. In my real-world benchmarks -- no, CPU rendering for the purely 2D case is vastly more efficient than trying to shoehorn it into OpenGL.
- stannol 10y ago> 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.
- joezydeco 10y ago"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.
- kbart 10y ago"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.