Tegra K1


Some things just don't have a translated instruction in the GPU that are optimized and has to be done "the long and expensive way"
This is true, but it is also true on desktops: sometimes the hardware just doesn't support a feature and the library needs to compensate; sometimes the driver will say that it supports a feature but really it doesn't, at least not in hardware, and the driver is doing it's own software fitzing to make it work; sometimes it does support it in hardware but it still needs to do some CPU and memory work to use it. There is nothing especially unique going on with the OpenGL shim other than the drivers for the hardware only report that they support the OpenGLES functions. Yes, the OpenGL shim has to do more work translating function calls and keeping stuff in memory but a lot of that stuff would be happening in the driver anyway, so it isn't necessarily adding anything. Sure, some overhead must be added, but to argue that it's "long and expensive" in a noticeable way seems extremely naive. Have you read the shim code? It's pretty well written.
it was my understanding though that just as RISC is to CISC is that opengles is to opengl compliance in hardware
That's a gross simplification but I don't have the background to demystify it. Technically true, but when most of the calls to OpenGL have equivalent ES calls there's not really as much difficulty in conversion as you may think (I mean on the CPU end, lunixbochs figuring out all the conversion stuff required was most definitely a difficult endeavor)
 
Specs of OMAP 5 sounds nice on paper, I hope that the Pyra can get this power also straight "onto the road". I hope there will not be issues like the Pandora suffered from like "We have a DSP but we can't use it because of XYZ..."
I'm also curious what's exaclty behind these specs here:

  • Multi-core POWERVR™ SGX544-MPx graphics accelerators
  • Dedicated TI 2D BitBlt graphics accelerator
 
Last edited by a moderator:
wizardstan- like I said my knowledge is just general knowledge, if it's superficial and has no noticeable impact on performance then sure. My common sense just says that things done on a processor designed to do those things would be better than having to do it in software or on a different processor all together. ASM vs HLPL and native vs emulated. If the scale of the problem is off then there's really no problem at all.
 
Last edited by a moderator:
Then there's probably no problem at all.

edit: which is to say that the problem is on lunixbochs working his magic to figure out the missing calls and write the conversion functions, not that it's necessarily causing it to be slower than if the driver supported native OpenGL calls.
 
Last edited by a moderator:
why do you keep saying I'm "failing to realize" or "failing to understand" like you're soehow bringing up a point I haven't already thought about.
Because you just throw a bunch of opengl games as an argument which answers nothing because you don't even begin to address the fact that porting needs more than just OpenGL for these games to work.

If you want to have an intelligent conversation, act like a reasonable person in the first place and try to understand the world does not revolve around what you want.
 
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.
Keep in mind that a 64bit CPU hardly provides any advantages for us, concerning 64bit software it may actually perform slightly worse in a general purpose context.

Looking back at the 32->64 bit transition of the x86 architecture, the small plus in overall performance actually came from other improvements: Lots of new general purpose registers, passing arguments of functions in registers instead of using the stack, some more efficient commands for random stuff... and of course the fact that stuff like SSE2 is always available.


You generally get a significant drawback by switching over to 64bit due to memory overhead etc, which might get compensated to some degree by getting the chance to get rid of old cruft. x86 had a lot of legacy stuff and restrictions for a good backwards-compatibility, so the result was quite good. I doubt that there's that much room for improvements for the old 32bit ARMv7 architecture, especially since backwards-compatibility has never been that important in the past (someone might correct me on this if I've got a wrong impression).
A little late on this, but I'm pretty sure ARMv8 has twice as many general-purpose registers. Similar performance increases are possible.
 
There is a good reason why OpenGL|ES was invented in the first place, and that reason still holds. Full OpenGL got bloated with redundant features that are not often used, which complicate the GPU design if they have to be supported in hardware. Power consumption was not taken into account when OpenGL was originally designed.

People seem to think that if we put an x86 SoC in the Pyra, with a GPU like in a gaming desktop, it will be able to run all current commercial PC games out of the box (even if the battery would only last half an hour and the device would burn a hole in your hand). That assumption is simply not true. The game would still need to be adapted to a handheld: most likely it will not be designed with a 5" screen and two nubs in mind, but rather with a 21" monitor and a mouse+keyboard. If it's a closed-source commercial title, there is no way that this adaptation is going to happen.
 
Also even the sgx in the Pandora is OpenGL 2.x and DirectX 10.0 compatible.


It is used in x86 atom socs, too.


The driver for arm just gives GLES 2 as it is intended for non bloated mobile applications.


OpenGL itself went this route not long ago and if you only had OpenGL 3.0 support in modern graphics drivers you would also be roughly limited to the subset of instructions GLES 2 gives you.


For features:


I think the PS3 has an OpenGL similar to GLES 2 and you know what is possible with this.


The Tegra 4 was announced with OpenGL support, but has any OpenGL driver materialised on arm?


I think not.


So lunixbochs is basically reimplementing what desktop GPU drivers do only for compatibility these days.
 
Last edited by a moderator:
As said numerous times:


If you want a nvidia soc you don't only have to buy a lot of them in advance as you won't know when they will stop producing them, but you also have an order minimum. Also if you want to buy the socs you need to use a nvidia certified design company for the board design.


If you want to produce millions of devices all of that is fine but if you don't know if you will sell even 5000 of it in advance, you simply cannot take this big risk.


If you have some spare money (about $5000000 might be enough) and don't mind if the parts that are bought with this might never be sold and the expensive boarddesign is never used again, please send it to ED and he can start to get in conversation with the big players.


But until nobody wants to sponsor that money, I don't think ED will go anywhere near nvidia or Samsung.
 
Last edited by a moderator:
is the reason for "no" really that their minimum order too high?
That's their history, yes, historically you need orders of many tens of thousands if not hundreds of thousands before they'll even consider talking to you. They may be changing that stance as of the K1 but I wouldn't count on it.
 
I just looked it up 100,000 moq, they have hardware partners for lower quantities, but none of them have tegra 4 or k1 in their product listings

https://developer.nvidia.com/tegra-hardware-sales-inquiries

so yea, well outside the scope of this I'm sure unless ED sells off the 80,000-90,000 he won't need

rumor is that price per part is like $21/ea so 2.1mil individual investment or by a group of designers/manufacturers 
 
Last edited by a moderator:
If Pyra uses K1 then I only have one (1) additional toy to own in the near future, and that would be the Pyra. If Pyra uses OMAP5 or some other SoC, then I will have two (2) additional toys, and they would be Pyra and Shield 2 :D
 
If Pyra uses K1 then I only have one (1) additional toy to own in the near future, and that would be the Pyra. If Pyra uses OMAP5 or some other SoC, then I will have two (2) additional toys, and they would be Pyra and Shield 2 :D
So: Win Win situation. ED doesn't need to ruin himself and you have multiple toys to play with ;)
 
rumor is that price per part is like $21/ea so 2.1mil individual investment or by a group of designers/manufacturers
Unfortunately, the price per unit is significally higher than just the SoC. In fact, it'll probably be at least 300 - 350 EUR per device, so it would need an investment of 30 - 35 Million Euro...


Sent from my Xperia Pro using Tapatalk
 
I was more saying is sell the leftover SoC's instead of selling complete units, or better yet purchase the leftover soc's from another manufacturer instead of through nvidia directly. Whatever MadKatz didn't use for their mojo for example (not a real example) but I doubt they'll sell 100k of their things. Might even be able to swing a discount as they will be wanting to get rid of their surplus.
 
Last edited by a moderator:
I don't think nVidia would let him sell any loose chips. It's usually a big enough pain to even get chips exported from the US due to trade restrictions.
 
If he does that (buying leftovers) he won't get any support or warranty from nvi dia directly what could be suecide in this business.


And who would even have leftovers of a not even released soc that they don't need for themselves?


If he wants to sell them he needs a pretty solid deal. Also he needs to purchase them upfront. Far too risky for my liking...


Edit: what slaeshjag said is of course another thing that can complicate it. Who knows how a contract at nvidia would look like?
 
Last edited by a moderator:
a joint venture might be more attractive then? I can't see who would be looking into this that wouldn't be seen as competition.
 
Back
Top