Tegra K1
- Thread starter EssoAir
- Start date
God Ginrai
Godmaster
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:
Saber
Advanced Member
- Joined
- Jan 23, 2012
- Messages
- 1,303
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.
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:
Hồng Thất Công
Đả Cẩu Bổng Pháp
Dump all the Retroarch filters into the extra core and make all retro games HD
Null
Snug
^
Last edited by a moderator:
Letalis Sonus
Advanced Member
- Joined
- Mar 5, 2009
- Messages
- 1,530
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.
slaeshjag
¯\_(ツ)_/¯
^ 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.
Exophase
Nothing good will ever come of Exophase.
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.
Letalis Sonus
Advanced Member
- Joined
- Mar 5, 2009
- Messages
- 1,530
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.
Exophase
Nothing good will ever come of Exophase.
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:
ShleeDragon
Pro-Catflip
- Joined
- Aug 28, 2010
- Messages
- 1,749
what a hipster.. tears of a lumberjack for you.
Last edited by a moderator:
God Ginrai
Godmaster
Might want to edit your post. You're currently making EvilDragon look like he talks about himself in third person.
-God Ginrai
-God Ginrai
Null
Snug
Last edited by a moderator:
bzar
A Commando
You are overusing that one
SNESFAN
Retro game fanatic
Null
Snug
FFS are people never happy?You are overusing that one
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.
Similar threads
