What boards should element14 carry besides the Raspberry Pi?

Maybe we can come up with a list of which board characteristics we would

like to see.  For example:

a.  SATA is a plus

b.  ARMv6 is a minus

c.  1080p decode is a plus

d.  trouble-free, mainlined USB driver is a plus

e.  1.8v UHS SD card support is a plus

f.  HDMI that can power HDMI to VGA converters is a plus

g.  ethernet over USB is a minus

h.  closed source bootloader is a minus

i.   lack of hot-plug USB thumb drive support is a minus

j.   plastic SD-card holder is minus

coder27 wrote:

 

e.  1.8v UHS SD card support is a plus

I've yet to see a board that supports that. Schematics for all the ones I've got so far show the SD card hard wired to 3.3v.

I'll add,

k. full sized SD, especially where the card hangs over the edge of the board is a minus

l. accelerated X11 drivers are a plus

m. reasonable number of gpio is a plus

and I'd maybe modify b, to be ARMv6 or earlier

n.  boot from USB/ethernet/SATA is a plus

o. battery backed RTC

> l. accelerated X11 drivers are a plus

Accelerated X11 drivers are in the land of broken promises.

Liz wrote on Feb 17, 2012:

"We're going to be offering a bounty for the best accelerated X implementation from the community - more news about that after launch."

http://www.raspberrypi.org/phpBB3/viewtopic.php?f=2&t=3145&start=20

Liz wrote on Oct 15, 2012::

"Accelerated X will be a solved problem soon; we've put engineering resource on it, and it's actively being worked on."

http://www.raspberrypi.org/phpBB3/viewtopic.php?p=194400#p194400

but Simon (working on his own) has apparently given up, writing on May 7, 2013:

"Nay, I didn't have much time to work on it at the beginning of the year. When I did restart there were some weird bug reports which I could never repro, then I realised that it's just not worth the effort...the demand for an accelerated X is much lower than you might imagine."

http://www.raspberrypi.org/phpBB3/viewtopic.php?f=63&t=4649&start=396

Earlier he described the problem as essentially fundamentally unsolveable

due to X applications doing too many single-pixel operations that are

impossible to accelerate due to the overhead involved in gpu communication.

There is perhaps hope for X applications such as web browsers to

switch to a different toolkit that can be accelerated, as is done with

most cell-phone browsers.

coder27 wrote:

 

Earlier he described the problem as essentially fundamentally unsolveable

due to X applications doing too many single-pixel operations that are

impossible to accelerate due to the overhead involved in gpu communication.

That's mostly an implementation detail of the Pi's unusual architecture. Other GPU's manage it fine in x86 land even if it is with closed drivers.

I agree that gpu stuff is currently off in the clouds playing with the flying pigs.. Still, if someone pulls a rabbit out of the hat, or if the lima project gets useful then a group of sbc's using whichever gpu will become much more attractive.  Which puts pressure on competing vendors to do the same.

No, I'm not holding my breath waiting

coder27 wrote:

 

Earlier he described the problem as essentially fundamentally unsolveable

due to X applications doing too many single-pixel operations that are

impossible to accelerate due to the overhead involved in gpu communication.

That's mostly an implementation detail of the Pi's unusual architecture. Other GPU's manage it fine in x86 land even if it is with closed drivers.

I agree that gpu stuff is currently off in the clouds playing with the flying pigs.. Still, if someone pulls a rabbit out of the hat, or if the lima project gets useful then a group of sbc's using whichever gpu will become much more attractive.  Which puts pressure on competing vendors to do the same.

No, I'm not holding my breath waiting

>That's mostly an implementation detail of the Pi's unusual architecture. Other GPU's manage it fine in x86 land even if it is with closed drivers

I'm not sure how much to attribute to the Pi's unusual architecture, as opposed to simply

the Pi's slow cpu in comparison to x86. Simon has done experiments where he replaced

all his gpu acceleration with noops, and it still ran slow.

http://www.raspberrypi.org/phpBB3/viewtopic.php?f=63&t=4649&start=58

I think X applications is one area where the BBB's faster cpu will show a significant

improvement over the RPi.  Hopefully the RPF will have a faster cpu ready soon,

or else focus on non-educational markets where X speed doesn't matter.

I see the May issue of the MagPi magazine has an interview with Pete Lomas where

he says the educational release is still planned for the future, so it doesn't look like

they've completely given up on the educational market.

coder27 wrote:

 

I'm not sure how much to attribute to the Pi's unusual architecture, as opposed to simply

the Pi's slow cpu in comparison to x86. Simon has done experiments where he replaced

all his gpu acceleration with noops, and it still ran slow.

Slow is relative though. Direct comparisons between a $35 sbc and a $1000 water cooled gpu are a bit unfair and will seem slow in comparison. The trick is to find out if accelerated X11 drivers on the Pi can be faster than dumb framebuffer on the Pi.

Other architectures and other GPU's go the accelerated route because it is faster than framebuffer. If it's not on the Pi then maybe there's an inherent design limitation.

IMHO as long as these boards want to have a full desktop installed then X11 drivers will be an important issue as people will see the difference compared to their expensive PC. The BBB is just as guilty here, their onboard Angstrom build boots straight into gnome.