Tegra K1


 


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?
If I had a nickel every time someone has said they can't port something because some open source project used openGL instead of opengles... I'd have like a dollar lol

but seriously, these are some of the games that would become portable (the ones under open source of course)

http://en.wikipedia.org/wiki/List_of_OpenGL_programs

not to mention the shared library of games being rolled out for use on tegra chipsets and the ones in the future (if android gets ported of course)

if it's not worth it, then I understand,
 
Last edited by a moderator:
why is ED still asking those kinda questions then?? Pointless conversation is pointless, and nobody other than ED would know how pointless it was to begin with. If this conversation defies logic, then I'd hate to see the rational behind some of the questions he's asking then. 
 
why is ED still asking those kinda questions then?? Pointless conversation is pointless, and nobody other than ED would know how pointless it was to begin with. If this conversation defies logic, then I'd hate to see the rational behind some of the questions he's asking then.
There's no hurt asking what people want, to know the direction. Feasibility is a totally different thing.

Elon Musk is asking people "do you want to go to the Moon" and people are saying "yes", but right now he cannot send them there either. That does not prevent him from having a long term plan to address that.

You are missing the point.
 
I did miss where I was responding to essoair, this whole time I thought I was responding to ED asking what the tegra could do that the omap can't. Silly me.

And since you answered for ED then I guess you're him, so we're back on track then.
 
Last edited by a moderator:
Lets see what happens. I guess ultimately ed can only get what he can get.


Im more interested in having some other cool feature myself.


Stuff like the shield looks cool too.


I promised myself to only get a ps4 and a p2(pyra) this gen.


I already have a vita and I 'm very happy with that.
 
this whole time I thought I was responding to ED asking what the tegra could do that the omap can't. Silly me.
Apart from providing a link to OpenGL games, I don't see where you actually answered the question, since we are already running OpenGL games on the current Pandora. (OpenGL 1 with glshim)
 
Last edited by a moderator:
I guess it's a non issue then if you completely disregard native compliance and replace it with a comparability layer. Hell who needs open standards anyway right?
 
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.
(off-topic)

Don't want to derail the thread but... will the keyboard of the Pyra be more like the Xperia Pro than the current Pandora?

As another Xperia Pro user, I find myself preferring to code in the Xperia Pro than in the Pandora, as I find the keyboard a lot more pleasant. Specifically it is using vim (inside Lil'Debi/debian chroot) to edit C and bash scripts. NOTE: I have a customized keyboard layout on CM10 with Esc, Control(...) to make that possible.

Thinking about it, the two things that I miss most when using the Pandora are: the smaller travel in the Xperia Pro makes typing easier, and having both modifiers (shift and Fn) in the same side (left) is more convenient. Bonus: you can push both modifiers simultaneously with the thumb to get additional characters.

(/off-topic)

Back on topic, I concur that the processor is not the most important feature of a portable device. IMHO it is having an operating system adapted/optimized to the idiosyncrasies of the hardware (hey, I'm a software guy...) so the machine can really shine.
 
I guess it's a non issue then if you completely disregard native compliance and replace it with a comparability layer. Hell who needs open standards anyway right?
Hyperbole and sarcasm aren't your friends when trying to convince other people they're wrong. State exactly what you mean to say without the rhetoric.
That being said, your opposition is misplaced. OpenGL is a compatibility layer, that's what standards are. You call a function in the OpenGL library, that library makes a call to the graphics driver, that graphics driver sends electrical pulses to the graphics card, the graphics card pops up a picture on the screen. Every graphics card is different, they have different features and different ways of handling equivalent features. The OpenGL standard (along with DirctX and VESA) is a compatibility library which brings all these different things together into a consistent library: when the driver supports a feature natively the library passes it along without interference, when the hardware supports a feature but under a different name in slightly different ways the library does some conversion, when a feature cannot be handled by the hardware the library takes over and does it in software. And even that's not all there is to it; OpenGL is not "a library", it's just a standard set of function calls. There's an implementation library of that standard for Windows, and implementation of that standard for Mac, and at least 2 different implementations of that standard for Linux.

The OpenGL shim is exactly the same, it is a library that (hopes to fully) implements the OpenGL standard. When the driver supports a feature, it makes hardware calls directly, just like the library on your desktop. When the driver doesn't support a feature it does some work in software, just like the library on your desktop. The OpenGL shim is, for all intents and purposes, just a standard OpenGL library which works with a specific line of graphics cards which will be called "OpenGLES standard": we make a call to the OpenGL shim library, that library calls the driver when it can and software when it can't, that driver sends electrical pulses to the GPU, and pretty pictures appear on the screen, identical in flow to how the desktop libraries work.
 
Last edited by a moderator:
I am pretty cool with OMAP5 in the Pyra.

Only thing i am wondering is, will there ever be an OMAP6 with Armv8 cores? if so, would it be feasible to design the pyra around that?

If the omap6 wont be out anytime soon, then OMAP5 is the best choice in my opinion.

The tegra will give no benefit in emulation and VMs anyway...
 
Last edited by a moderator:
@wizardstan- thanks for the detailed answer, I'm familiar with how stuff like opengl generally works with instructions, and those instructions may have optimized routines in hardware. My comment and point was made with that in mind even if not completely received on the other end.

it was my understanding though that just as RISC is to CISC is that opengles is to opengl compliance in hardware. 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" I don't have detailed knowledge of what exactly is missing, but from things I've read there's some significant things. Having hardware that is compliant and having those instructions already in place electronically already has to always be better than not, I can't see how it couldn't.

My point is just as a ARM processor will never be as fast or efficient at doing certain things as x86 can do, the same can be said for stuff in the GPU.
 
Last edited by a moderator:
I guess it's a non issue then if you completely disregard native compliance and replace it with a comparability layer. Hell who needs open standards anyway right?
In the list of OpenGl programs you listed you don't seem to understand that simply having OpenGL is not anywhere enough to run them. Most of these games are for x86 architecture and you need Wine/Qemu to run them on ARM, and besides that many of them require significant processing power that you won't have in a Pyra-class of device anyway. And these games were not made to run on a 5 inch screen either, since the game text wont be readable on that size of screen. 

If you want to  play x86 PC games, get a x86 PC, it's faster than waiting for a Pyra. 
 
ekianjo- why do you keep saying I'm "failing to realize" or "failing to understand" like you're somehow bringing up a point I haven't already thought about. I'm done being talked down to by you. I've treated you with more than adequate respect. there's plenty of software that will benefit from standard opengl support piss off.
 
Last edited by a moderator:
Back
Top