Search results for query: *

I'd love a "playground" device like this too - you can even get fpgas with arm hardcores and ddr interfaces that can boot linux and act as a host for the fpga logic - allowing you to even modify stuff "live" on device. But I don't know if they have framebuffer/display out and stuff like that...

From what I remember they actually pretty much shut down all their SoC development teams - I guess the pi is just enough to keep them limping along doing "least effort" refreshes with what IP they already have lying around (or pretty much complete but not yet in product when they did that), or...

If there's *anything* even close from AMD/Intel/Broadcom to the power envelope possible here I would strongly prefer those. I really dislike giving companies dollars when they haven't earned them - even if they have a "good" open source driver, I feel they're taking advantage of the community...

Nearly all SoCs can be tuned for a specific power use (and heat output) - they just clock lower. No need to create a new SoC for each power target when you can just wind the same silicon down for the same result. This same point should be kept in mind when considering any lower performance core...

My dream CPU board will be able to run dolphin. That needs: - 64-bit arm (the 32bit jit was removed as it was a maintenance and performance nightmare) - wide frontend (the jit hates the narrow/in order cores like A53 and A55) - Decently fast dual core CPU (a57 at ~2ghz sustained can just about...

Unfortunately, while the A53 on the i.mx8 will be useful with supporting armv8 and aarch64, and a "good" open source GPU driver a massive plus, the end performance of an A15 will likely be quite a bit higher at the same clocks. Same with the GPU, which is nice and fancy and supports GLES3.1, the...

Morally there's nothing wrong with using tantalum *if* you can verify the supply source. It may be more expensive, and it may be more work, but I don't see why you should avoid a component just because some components are manufactured using materials with questionable sources. And generally...

Annoyingly, there's quite a few hardware features on the SGX544 that are not exposed through the gles2 driver... I'm sure if anyone had a few $million they could try to encourage an open license for docs... but until then it's just a little frustrating :)

...of the time, as "most" OpenGL 2 apps don't actually use those features. (Though it's likely most semi-modern GPUs are flexible enough that they *could* support pretty much anything, the question is if it's really worth the software cost for a slow workaround (which may be even slower than...

OpenGL2. None of those features are in GLES2.

The videocore IV doesn't "technically" support OpenGL2 in hardware - there are some missing parts (occlusion queries, quads, 32-bit index arrays, shadowmap texture lookup) that are unlikely to ever be worked around - but "most" OpenGL2 apps don't use them. And so long as they don't it'll work...

...without a VM, though you still have to trust any exposed devices within that container (which would include the gpu driver for one, though this *is* open source and it's MMU interactions can be verified, it still runs a closed firmware and verifying all the code paths in the 'open source...

I'm not sure I see the point of this being attached to a "faithful" zx clone - it'll be "so" overpowered that you may as well do everything on the PI. Then I wonder what the point of having the attached zx would be? It feels kinda cheating :)

Plus, a "single sentence" idea is dime a dozen. Something where all the mechanics and interactions are thought through and well defined is *not*. An "elevator pitch" is nowhere enough to start developing a game in my opinion (unless you intend to "find it as you go along", which means it...

...exactly what core is on the SoC. It's not driver 'state' as such. Note, that the sgx driver model means that a binary driver must match both these *exactly* to work. Even revisions changed how things work in non-compatible ways. I believe the other values don't really have any use unless you...

All yours for the low cost of 1.989 × 10^30 kg Hydrogen!

...support (IE no h.265, and the omap cpu won't have a chance for a sw decoder implementation at realtime speeds) The sgx itself is not used to decode video. That's a different block. (though it *can* resize/resample/post-process video after it's decoded, but that tends to be lower-effort anyway)

...runtime, so you can use the same driver on different cores too. But that's not useful here, as sgx is a ~3 generation old product on a ~10 year old codebase. And you probably could fit a binary of *every* driver we've ever shipped in a 300mb zip. I suppose that's one way of having...

A *Huge* cost of anything attached to any automotive product is the verification, to *guarantee* that nothing can accidentally tell your car to "ACCELERATE A FULL POWER GOGOGOGO" because an app crashed, and that "necessary" processing is guaranteed a timeslice and not denial-of-serviced. This is...

...a few chips but they're a different division and not interesting here) don't produce hardware directly (outside of some internal-only testchips you *really* don't want to use). This means that to even get anything working there needs to be some SoC-level integration added to our 'reference'...