Two Ls!
I can't tell for sure, but it looks like it was rendered at < 720p and upscaled.Epic Unreal Engine 4 "Rivalry" demo on TK1 for Google I/O 2014:
https://www.youtube.com/watch?v=X-tAZtbDZ8E#t=61
Two Ls!
Two Ls!
I can't tell for sure, but it looks like it was rendered at < 720p and upscaled.
I can't tell for sure, but it looks like it was rendered at < 720p and upscaled.
That controller looks terrible.Google Android TV reference box (based on TK1):
Looks very very compact to me
I don't think it's YouTube. Looks like sub-HD and a fairly annoying chromatic aberration pass despite not really being shot through a lens. Nice art, lighting (even though it's mostly baked) and a stable framerate, which are all things for me to point my demo team at, to achieve in their workYoutube H.264 super-duper-blur (TM) ?
There is an article on either Arstechnica or Engadget that Google also "invented" its own low-level Graphics API (like Mantle, Metal, DX12).
Is there any proof of that ?
I don't think it's YouTube. Looks like sub-HD and a fairly annoying chromatic aberration pass despite not really being shot through a lens. Nice art, lighting (even though it's mostly baked) and a stable framerate, which are all things for me to point my demo team at, to achieve in their work
Two Ls!
Incidentally, driver overhead due to API design (say, OpenGL ES compared to Metal) is huge. It's an issue in certain circumstances.On that note, I think you'd similarly agree that if there was a 50% overhead due to language for GPU drivers it'd be a big deal.
Yes, but I don't think anyone made such a blanket statement.I'm not saying optimize everything blindly here or that less efficient languages aren't fine for plenty of tasks, just that blanket statements about 50% performance not mattering make as much sense as saying that CPU perf dropping 50% doesn't matter. Good programmers will be able to determine when optimization is and isn't suitable. Thing is, a lot of programmers today don't have the faintest idea of performance implications of what they program and are neither aware of performance issues with the language they use nor how to optimize at all.
I don't see why that would be limited to cases where you need platform specific branches.As for your claim about writing faster code with slower languages because it saves budget time that you can use on better optimization, I could see that being true if optimization with the "faster" languages would mean more platform specific branches. Otherwise I'm skeptical, especially if it comes down to Java vs C++.
Incidentally, driver overhead due to API design (say, OpenGL ES compared to Metal) is huge. It's an issue in certain circumstances.
Yes, but I don't think anyone made such a blanket statement.
I don't see why that would be limited to cases where you need platform specific branches.
http://evleaks.at/2014/07/02/htc-vo...-final-8-9-1680x1050-ship-2560x1600-64gb-5mp/
I'd be perfectly fine with 2GB for it; it just doesn't sound like availability before early 2015
http://evleaks.at/2014/07/02/htc-vo...-final-8-9-1680x1050-ship-2560x1600-64gb-5mp/
I'd be perfectly fine with 2GB for it; it just doesn't sound like availability before early 2015