Tegra K1


What do I make of this?

Link
Nothing. That's a board not an SoC. The SoC on that board is a Snapdragon, from Qualcomm, which we have already noted will not sell to EvilDragon in small quantities.

-God Ginrai
I misunderstood and thought it came with it. Well, that's what I get for trying to help. lol 
 
Last edited by a moderator:
So, some people still are more impressed by specs than what a device actually can do?


I could never understand that.


I'm still using my xperia Pro as phone, as there's not a single smartphone out there with a keyboard... and smartphones have become so huge.


And it does everything I need.


Modern phones don't impress me at all. They've got plenty of horsepower that most people will never use... so what for?


Same for the K1. Impressive GPU, sure - but honestly, what do you expect from it that won't run with an OMAP5 GPU?


HQ Commercial games? Will never be released on the Pyra anyways.


Dolphin? Maybe right now, but I honestly don't believe it needs OpenGL ES 3.0. Sounds like they didn't optimize it much for slower GPUs, but that can be done.


So, honestly, what do you expect that the K1 can do that an OMAP5 can't, when ignoring commercial games?
Totally in agreement with you here. If the Pyra is everything we've heard rumored of, an updated OMAP5 Pandora with a 1080p display and refined keyboard and case, it's already won loyalty and community endorsement regardless. Nvidia can have their bowling ball weighted, monster controller. Not every person wants or requires a nose bleeding edge type device for portable PC and gaming on the road.

A master of all jack's trades is more than sufficient. ;)
 
Last edited by a moderator:
Going to tend to agree with Saber in this case.


In terms of throughput an OMAP5 equipped Pyra should offer around a 2.6x-3x improvement per core, and be better able to utilize that potential due to scheduler improvements, an out of order engine, and generally being newer and more refined.


The OMAP5 looks like it does have good options for offloading various types of dedicated processing, even if one can poke at it being a dual instead of a quad core in terms of general processing. I imagine that its dedicated 2D GPU and associated power management design should help with battery life when handling the desktop and a lot of classic games that don't really call for what a 3D GPU offers.


My understanding is that most of the code associated with what the Pyra would be aimed at is designed to mainly operate on a single core, with an additional core being nice but not fully utilized as part of offloading things. As far as I'm aware the relevant emulator projects haven't yet developed code that is designed to exploit a quad core processor.


In terms of GPU going off wiki the OMAP5 5432 has a SGX544MP2 running at 532 MHz, which should be dramatically more powerful then the SGX530 in the Pandora. Along those lines I found some press stuff indicating that TI was getting in Apple's grill associated with claiming superior GPU performance versus the iPad 3 associated with this (link).


While not bleeding edge on paper it looks like a well featured and well supported option that can reasonably handle what software could be reasonably supported by even the current bleeding edge stuff, and has advantages related to minimizing chaos related to being able to take advantage of the existing software base. I don't see how it's a bad option, or not a reasonable compromise.
 
Last edited by a moderator:
^

screen_shot_2012_04_28_at_19_21_50.png
 
Last edited by a moderator:
A little late on this, but I'm pretty sure ARMv8 has twice as many general-purpose registers. Similar performance increases are possible.
However, x86 was very tight on registers to begin with. You originally only had 4 registers available to work with, and you often had to keep them free because each of them is bound to certain commands. This pushes you to work mostly on the stack, keeping often used data in registers is a bit tricky. Adding in 8 completely free registers generally allows a quite large change in how things are done.
Coming from RISC, 32bit ARM already has quite a lot of registers and you are pretty much free to choose what to do with them. More registers wouldn't cause a large change like that, you'd need to work with a lot of different variables at the same time to really get a nice benefit out of it.
 
^ You actually have a few more that you can shuffle stuff into temporarly. But x86 is pretty strict on what you can use registers for, they all have a defined function.
 
However, x86 was very tight on registers to begin with. You originally only had 4 registers available to work with, and you often had to keep them free because each of them is bound to certain commands. This pushes you to work mostly on the stack, keeping often used data in registers is a bit tricky. Adding in 8 completely free registers generally allows a quite large change in how things are done.
^ You actually have a few more that you can shuffle stuff into temporarly. But x86 is pretty strict on what you can use registers for, they all have a defined function.
You guys both sound like you didn't do a lot of coding in protected mode. I've done a fair amount of 32-bit x86 code and never had a problem using 7 registers liberally, only avoiding esp as a GPR. The 32-bit extensions made things a lot more orthogonal. Of the instructions that still had implicit operands many have become too slow to be useful. A lot of the other ones are either infrequent or expensive enough that the overhead of shuffling registers around is negligible. The only one that really felt annoying was variable shift being bound to cl (not even the full register), but even that doesn't tend to come up very much.
 
I have done more reverse engineering stuff than actually working productive with x86 assembler to be honest, but everything compiler-generated I have seen so far didn't seem to use the other registers at all.
 
I have done more reverse engineering stuff than actually working productive with x86 assembler to be honest, but everything compiler-generated I have seen so far didn't seem to use the other registers at all.
If this is happening with 32-bit code then it's probably a sign of weak (possibly because they're old) compilers or poor optimization levels.
 
Last edited by a moderator:
said: Well the K1 with dual core 64bit armv8 will be out in products around mid this year, making the OMAP5 at least 1 gen old. By the time the Pyra launches - hazards a guess - next year, it could be 2 gens old. But if that's the only chip ED can get, well it's disappointing as SNESFAN said, but what can can you do
what a hipster.. tears of a lumberjack for you.
 
Last edited by a moderator:
Might want to edit your post. You're currently making EvilDragon look like he talks about himself in third person.

-God Ginrai
 
So, whoot, it shows that the latest SoC with a GPU from a developer mainly known for Graphics card is faster with 3D stuff than the other ones.

Not really surprising, that what was I expected when I read the announcement.

The CPU is not even tested here, and I still doubt you can expect 3D games on the Pyra that need that much 3D horsepower... that's mostly for commercial game development.
 
Back
Top