It had to do with validation and time to market. Unfortunately I can not tell you yes or no, in regard to future SKU, since we aren't allowed to talk about future products.
Hi metaplinius -
I am from Intel, and on the Edison team. There were reasons for the GPU being fused out - namely that the use cases around what is intended for Edison do not need video. That said, it may not be that way forever. I'd love to hear from the community on what they think of this feature being enabled - lots of voices make it easier for me to sway opinion.
I for one am a huge fan of video streaming, and also would like to see this. I've tried and failed many times making a Pi do what I want as a NAS and/or streamer.
I also would like to see ISV stuff exposed so we can hook up cameras directly and make use of HW acceleration.
Like I said, please be vocal in the community - we are listening!
I could be wrong
but the boards may be possible to embed a video card later?
from what I saw the idea is that it is a sign of development of scalable, for this reason I believe it is a matter of time until one board that has a gpu arise
Thanks very much for the answer. I figured that the reason would be something like that. Anyway, now you know what I think of that. It would just be too cool to have a whole x86 computer in such a tiny form factor. Also, I got into OpenGL a few months ago and I really like graphics cards now. It would be nice to have such a relatively low power (both by electrical and computational means) system like the Edison and do that stuff in that environment. So something that is very similar to what could be done with a Pi or a Beaglebone, just with a real x86 processor and graphics hardware that could actually do OpenGL (and not the ES version).
Thanks for the answer and I'll be curious for future developments!
i'd definitely love to see the gpu enabled (via OpenCL access). it would open a lot of applications. not just video streaming but vision processing for natural human interface applications or automated recognition. even geom processing for 3d printers. acoustic processing would also benefit for real time voice recognition without the cloud (that has large latency).
While I'm unsure of the ability, it would possibly be a positive route to use MHL as the onboard video standard, though MHL does require additional hardware to implement in some cases, I have a device which uses it in a 5 pin USB connector, though the company later switched from the standard USB connector to a pin compatible proprietary connector to allow the USB controller of their devices to be accessible by the adapter.it does exist as an option.
I only really bring up MHL because it would allow for physical compatibility with existing boards, meaning it would be backward compatible with existing breakouts and would only require commonly available MHL adapters, while new boards would be able to add an MHL to HDMI bridge to add HDMI capability using the same pinout.
Alternatively we do have some GPIOs we could switch to HDMI signalling, either through reassignment, or for MUX enabling. The signal pairs would take... about a row of the mini-breakout adapter (12 pins for those interested out oof 14). Though again, MHL is an option that would work well with existing hardware.
Adding my feedback, hope others will as well. I would definitely be in favor of having as many options available as possible.
Hopefully a solution could be reached where the user of the device has the choice. If you don't need the video core? fine, leave it disabled and save power. Want to use the video core for OpenCL to offload processing from the 500mhz cores, image processing for video streaming, OpenCV, external video (via MHL in a later revision or a custom board routing signal through gpio) then enable the video core.
That said, I understand that there could be license fees associated with the use of some video features/codecs, additional testing and certification required, etc. So Intel may have disabled the video core in the edison's current design either to keep cost down or as earlier indicated to facilitate time to market and focus on what is believed to be the primary use case for the device. Given the choice, I hope that the focus remains on closing issues like SPI latency and DMA, expanded documentation, etc., but in the meantime if enabling the video core can be done or included in a future revision it would definitely be welcome.
+1 for everyone talking about how the use case is GPU for things like opencv. It's not about attaching a monitor (although that wouldn't be a bad thing) and watching video.
Agreed - there are many use cases beyond displays that we are looking at.
In 2013 I created a series of openGLES tutorials for Raspberry Pi and would love to do the same for Edison.
if you're in London on Wednesday 29th you can join my talk on textures at the free Khronos London Chapter meeting:
perhaps someone from Intel Edison will drop by?
computer vision applications do not require a display,
neither do we,
Considering the 'use case' for the edison is IoT and robotics and 'intelligent appliances' as far as I can gather, I think removing the ability to use OpenCL on the GPU is a bit backwards and near-sighted. The Edison is too powerful and expensive to replace the MCU use case, but now too weak and under-featured to replace the embedded CPU+GPU use case when the 'competition' is giving us octa-core CPUs and OpenCL capable GPUs for a fraction of the cost and in *far* more 'open' platforms. I think the Edison is a highly confused design. I think removing the ability to leverage the GPU for OpenCL was a rather big mistake. Please rethink this, and when doing so look at what your competition is giving us for the same price or less!
I also hope you reconsider the very restrictive environment you've given us with the Edison - I've managed to get some bare-metal code running on it but it was a tremendous amount of work and involved fighting with your multistage bootloaders and flashing tools at every step. I really don't understand why you've worked so hard to keep it locked down when you claim you want people to 'tinker' and create with it. I think it's time to reconsider the entire design.
Perhaps there were power and heat considerations involved too.
Indeed, Edison should enable GPU.
In drone and robot community, video streaming and Image processing is very important, which requires GPU.
There are three candidates, and all has pros and cons
Pros: Good CPU power. nice support GPIO I2C PWM. Sparkfun's various device support. WIFI and Bluetooth. Yocto linux.
Cons: expensive. lack of GPU and Camera support
Raspberry Pi, Beaglebone Black, Intel Edison – Benchmarked.
Pros: Very good GPU and GPU. Direct Camera support. WIFI and Bluetooth. On-board GPS
Cons: lack of PWM. lack of thirdparty device support
Pros: great support GPIO I2C PWM. Cheap.
Cons: poor CPU and GPU. lack of Camera support. lack of WIFI and Bluetooth
Before DragonBoard 410c supports PWM, Edison should enable GPU to win default Brillo board competition.