On 08/01/17 12:58, Luke Kenneth Casson Leighton wrote:
On Thu, Jan 5, 2017 at 9:24 PM, Luke Kenneth Casson Leighton lkcl@lkcl.net wrote:
i'm not letting you off the hook here after you said that EOMA68's interfaces are "crippled", peter.
ok, so can you see what i did, peter? you laid down a challenge (to do better)... and after three days, you've not responded. you *provisionally* described an alternative standard... but did not follow through.
*that's* what makes the difference, here. it's *not enough* to say "the standard you came up with is rubbish", you have to *follow through*, and if you can't follow through then it's.... you know what i'm trying to say?
The compromises you made are a result of your goals. You wanted a standard that could be implemented with virtually any cheap SoC. That basically forced you into the decisions to use USB and parallel RGB.
Unfortunately USB has a reputation for poor performance and reliability. Some of this is possibly the fault of the USB standards themselves, some is a result of crappy implementations.
Intel has different goals, their job is to make something that takes best advantage of their own current and future products. EOMA68 does not do that, it drags it down to the lowest common denominator. As such I believe that by adopting EOMA68 Intel would be crippling their product. I gave some examples of interfaces I think Intel should include that were unsuitable for EOMA68.
I don't know exactly what Interfaces it would be best for Intel to include, that would require knowing both full details of the chips they plan to use in their current cards as well as their future roadmaps (if they have something on their SoCs today but plan to drop it in the future it would be stupid for them to put it on their compute cards).