NVIDIA Shows New Doom Demo On GeForce GTX 1080 (hothardware.com)

MojoKid shares a video showing the upcoming Doom game on NVIDIA's new GeForce GTX 1080 graphics card using the Vulkan API, quoting this report from HotHardware: At a private briefing with NVIDIA, representatives from id software came out on stage to show off the upcoming game...the first public demonstration of the game using both NVIDIA's new flagship and the next-gen API, which is a low-overhead, cross-platform graphics and compute API akin to DirectX 12 and AMD's Mantle. In the initial part of the demo, the game is running smoothly, but its frame rate is capped at 60 frames per second. A few minutes in, however, at about the :53 second mark...the rep from id says, "We're going to uncap the framerate and see what Vulkan and Pascal can do".

With the framerate cap removed, the framerate jumps into triple digit territory and bounces between 120 and 170 frames per second, give or take. Note that the game was running on a projector at a resolution of 1080p with all in-game image quality options set to their maximum values. The game is very reminiscent of previous Doom titles and the action is non-stop.

Comments

Is it *really* Vulkan?

[Anonymous Coward]

Doom was OpenGL and the open multiplayer test was silk smooth on my R9 390 at maxed everything.

Re:Is it *really* Vulkan?

[Z80a]

As far i'm aware, its easier to write vulkan drivers than Open GL drivers, so, its quite possible, but not for the reason they're stating.

Re:Is it *really* Vulkan?

[Anonymous Coward]

It may be easier to write drivers, but as a user, it's a complete pain in the ass.

And thats not even counting that this "released" API has crazy buggy drivers, and is already up to OFFICIAL patch level 11 after 6 weeks.
As a graphics engineer, Vulkan is making my life a living hell at the moment. I wish they had waited 6 months and actually finished it before release.

Must be nice to have such a high profile release that nVidia will give you a ton of engineering resources to pull it off.

Re:Is it *really* Vulkan?

[zapadnik]

Correct. Vulkan drivers are easier because they do less and contain fewer optimizations. The optimizations are pushed to the application developer to do. This is both a blessing an a curse:
the blessing is that application developers can gain better performance in some cases, as there is less hardware abstraction and they can gain more control over execution of graphics operations.
the curse is that the driver has fewer optimizations built in, and future drivers can't contain optimizations for games.

This approach is helpful where call overhead is significant, and on less-powerful devices such as mobile devices. On much more powerful desktop GPUs the real-world improvements of such an approach is less clear. In actual implementations with AMD Mantle and Apple's Metal on desktop-class GPUs there are mixed performance gains (sometimes faster than OpenGL, but also sometimes slower). Given the fact that the simplicity of the Vulkan driver pushes complexity to the application (more control, but more unavoidable work for application developers too) then this simpler-driver approach is actually less useful for most of the developers actually writing the applications. Think of the difference between OpenGL and Vulkan as the difference between using a Linux distro and creating a distro out of parts you choose. You can get better performance if you choose all the parts of your custom distro, but it takes a non-negligible amount of effort and is really only beneficial on low-end hardware where every cycle counts, rather than on high-end hardware where you can have cycles to burn in some areas so time-to-market matters much, much more.

Vulkan has its good points - but as a desktop OpenGL developer, it is actually a step backward for the kinds of problems I want to solve (a desktop jet-combat flight simulator to be run on mid- to-high end desktop/workstation class GPUs).

Re: Is it *really* Vulkan?

[Anonymous Coward]

But since they're not removing OpenGL support, you can keep using that and develop in the environment you know.

Re:Is it *really* Vulkan?

[allcoolnameswheretak]

The trend in normal software development is to make things simpler by adding more abstraction and more building blocks that accomplish more with less. Graphics programming however is moving the other way around. Abstractions are removed and everything is moving towards putting the developer into direct control of the fundamentals. As an amateur OpenGL hobbyist I was shocked when they removed the fixed function pipeline - which is great in principle - but suddenly it was expected of me to write OpenGL shades to accomplish the most elementary things such as moving or texturing an object. This seemed like a huge step backwards to me, from an amateur developers efficiency point of view.

It seems to me that low level graphics programming has become so advanced and complex, it is firmly in the hands of specialists now. If you're an amateur or hobbyist, I guess people expect you to use existing 3D frameworks, or better, engines, to take care of your graphical needs.

Re:Is it *really* Vulkan?

[ledow]

Correction: Doom 3 might have been OpenGL.

Doom was most certainly not.

In fact, it wasn't "anything" but register/memory poking, I imagine.

A sad state of affairs that a sequel's sequel is regarded as the definitive version after only 20 years.

Re:Is it *really* Vulkan?

[Anonymous Coward]

They spent a long time nailing down the requirements (the really important bit) and nit picking small things. But ultimately, there's no better test than "Get it out there as a 1.0 and used for real."

None

It might be hard on driver developers, but tough. You'll be glad in the end.

So will vendors, game developers.and game players.

Re:Is it *really* Vulkan?

[ArmoredDragon]

Given the fact that the simplicity of the Vulkan driver pushes complexity to the application (more control, but more unavoidable work for application developers too) then this simpler-driver approach is actually less useful for most of the developers actually writing the applications.

Since most developers use a pre-written game engine, presumably they already have the optimizations baked in before they start?

Re:Is it *really* Vulkan?

[Anonymous Coward]

As an amateur OpenGL hobbyist I was shocked when they removed the fixed function pipeline - which is great in principle - but suddenly it was expected of me to write OpenGL shades to accomplish the most elementary things such as moving or texturing an object.

I recall that glUseProgram(0) or something similar brings you back to the fixed function pipeline in what I'm working on. Of course I wish I could ditch it, but to support remote desktop work, I still need it. I have to detect remote desktop and then not use any shaders or related. I'm hoping Server 2016 will finally end this silliness with its hardware support of opengl in remote desktop.

Re:Is it *really* Vulkan?

[UnknownSoldier]

> As an amateur OpenGL hobbyist I was shocked when they removed the fixed function pipeline - which is great in principle - but suddenly it was expected of me to write OpenGL shaders to accomplish the most elementary things such as moving or texturing an object.

What?! You're too lazy to write 2 _trivial_ shaders and setup code???

0. You could always ask Reddit's /r/opengl for help you know? I hang out there and on /r/gamedev.

1. You write the boiler plate to create/bind a shader ONCE:

* glCreateProgram(),
* glShaderSource(),
* glCompileShader(),
* glAttachShader(),
* glLinkProgram(),
* glGetUniformLocation() // for each uniform in each shader

My C++ code _with_ comments is ~400 Lines of code. Here's the initialize() function, using SDL. The "hardest" part is tracking down the function prototypes but a little bit of searching the OpenGL.h files makes that easy too.

// Shaders - Attributes
oglGetAttribLocation = (PFNGLGETATTRIBLOCATIONPROC ) SDL_GL_GetProcAddress( "glGetAttribLocation" );

// Shaders - Buffers Create/Destroy
oglBindBuffer = (PFNGLBINDBUFFERPROC ) SDL_GL_GetProcAddress( "glBindBuffer" );
oglBufferDataARB = (PFNGLBUFFERDATAARBPROC ) SDL_GL_GetProcAddress( "glBufferData" );
oglBufferSubDataARB = (PFNGLBUFFERSUBDATAARBPROC ) SDL_GL_GetProcAddress( "glBufferSubData" );
oglDeleteBuffers = (PFNGLDELETEBUFFERSPROC ) SDL_GL_GetProcAddress( "glDeleteBuffers" );
oglGenBuffers = (PFNGLGENBUFFERSARBPROC ) SDL_GL_GetProcAddress( "glGenBuffers" );

// Shaders - Compile/Link
oglAttachShader = (PFNGLATTACHSHADERPROC ) SDL_GL_GetProcAddress( "glAttachShader" );
oglCompileShader = (PFNGLCOMPILESHADERPROC ) SDL_GL_GetProcAddress( "glCompileShader" );
oglLinkProgram = (PFNGLLINKPROGRAMPROC ) SDL_GL_GetProcAddress( "glLinkProgram" );
oglShaderSource = (PFNGLSHADERSOURCEPROC ) SDL_GL_GetProcAddress( "glShaderSource" );

// Shaders - Create/Destroy
oglCreateProgram = (PFNGLCREATEPROGRAMPROC ) SDL_GL_GetProcAddress( "glCreateProgram" );
oglCreateShader = (PFNGLCREATESHADERPROC ) SDL_GL_GetProcAddress( "glCreateShader" );
oglDeleteProgram = (PFNGLDELETEPROGRAMPROC ) SDL_GL_GetProcAddress( "glDeleteProgram" );
oglDeleteShader = (PFNGLDELETESHADERPROC ) SDL_GL_GetProcAddress( "glDeleteShader" );
oglUseProgram = (PFNGLUSEPROGRAMPROC ) SDL_GL_GetProcAddress( "glUseProgram" );

// Shaders - Debug
oglGetProgramInfoLog = (PFNGLGETPROGRAMINFOLOGPROC ) SDL_GL_GetProcAddress( "glGetProgramInfoLog" );
oglGetShaderiv = (PFNGLGETSHADERIVPROC ) SDL_GL_GetProcAddress( "glGetShaderiv" );

// Shaders - Uniforms
oglGetUniformLocation = (PFNGLGETUNIFORMLOCATIONPROC ) SDL_GL_GetProcAddress( "glGetUniformLocation" );
oglUniform1i = (PFNGLUNIFORM1IPROC ) SDL_GL_GetProcAddress( "glUniform1i" );
oglUniform4f = (PFNGLUNIFORM4FPROC ) SDL_GL_GetProcAddress( "glUniform4f" );
oglUniformMatrix4fv = (PFNGLUNIFORMMATRIX4FVPROC ) SDL_GL_GetProcAddress( "glUniformMatrix4fv" );

// Shaders - Vertex Attributes
oglEnableVertexAttribArray = (PFNGLENABLEVERTEXATTRIBARRAYPROC ) SDL_GL_GetProcAddress( "glEnableVertexAttribArray" );
oglVertexAttribPoi

Re:Is it *really* Vulkan?

[Anonymous Coward]

Can you clarify a bit? I've watched a number of the updated specs and most of them have been clarifications based on feedback. And much of the feedback has been pushed BECAUSE the specifications have been released, which caused many to start implementation. Which very much seems like a chicken and egg issue.

So what issues are you encountering because the issues I've observed in the specification updates don't seem like things which would profoundly impact driver developers even if their initial development was different than the clarified implementation?

Re:Is it *really* Vulkan?

[edxwelch]

> AMD Mantle and Apple's Metal on desktop-class GPUs there are mixed performance gains (sometimes faster than OpenGL, but also sometimes slower)

If it's slower, it's because of bad implementation. Either badly written drivers or badly written application.

For me, I welcome Vulkan. I don't have to tie myself in knots anymore trying to optimise draw call into batches. The only that OpenGL has that is better than Vulkan is compatibility.

Re:Is it *really* Vulkan?

[Anonymous Coward]

Yes, yes, be a smartass :-)

Shaders are conceptually more difficult than the fixed function pipeline. They are more flexible, but more difficult to think about.

When I want to quickly throw together a visualisation (3d graph or something) I can do it in the fixed function pipeline in 10 minutes.

If I want to do it in 'modern' OpenGL it takes me an hour or so to get back up to speed.

For someone who just needs 3d graphics programming about once a year the fixed function pipeline is definitely way easier to grasp. Thinking in discrete boxes that do stuff is just easier on the brain.

Re:Is it *really* Vulkan?

[Anonymous Coward]

You're right, Vulkan isn't for you because in 2016 developers with aims similar to yours shouldn't be writing any code that interfaces with directly with a graphics API, ever. That is a separate job done by the engine developers (think id, UE4, Unity), who are going to take the time to write a properly optimized implementation and present to you an interface suitable to whatever level of abstraction the engine is targeted at.

Re:Is it *really* Vulkan?

[allcoolnameswheretak]

My C++ code _with_ comments is ~400 Lines of code.

This.

And you are seriously calling me too lazy to do that?
Of course I can figure all of that out and just do it once. But that's not the point. Previously I could quickly hack an OpenGL application together in an hour. Since OpenGL 3 I would have to invest several days in figuring out how the new programmable shader pipeline works, with all the intricacies involved, learn a new programming language, and then I would have to actually type those 400 lines of code and debug all of my newbie errors, all of which might take me a dedicated week. By the time I finally get a triangle on screen I will have cursed 5000 times and probably lost interest in whatever simple thing it was I originally wanted to do.

Re:Is it *really* Vulkan?

[UnknownSoldier]

> Shaders are conceptually more difficult than the fixed function pipeline. They are more flexible, but more difficult to think about.

Not really if you understand the rendering pipeline:

* For each vertex, run the the vertex shader.
* For each pixel in the primitive, run the fragment shader

I'd highly recommend you watch:

* http://simonschreibt.de/gat/re...
* http://etodd.github.io/shaders...

Because it sounds like you still lack understanding the fundamentals.

> When I want to quickly throw together a visualisation (3d graph or something) I can do it in the fixed function pipeline in 10 minutes.
> For someone who just needs 3d graphics programming about once a year the fixed function pipeline is definitely way easier to grasp.

OpenGL 1.2 is _still_ available, even on modern platforms.

Hell, you can use the glPushMatrix(), and { GLfloat matrix[16]; glGetFloatv (GL_MODELVIEW_MATRIX, matrix); } to query the matrix to verify your matrix stack is correct.

If you want to continue to make excuses for why you don't want to learn modern programming fine, but you're doing yourself a disservice by remaining a dinosaur.

Re:Is it *really* Vulkan?

[zapadnik]

Actually this is not the case. In OpenGL 4 many of the fixed function pipeline operations for matrix handling etc have gone. You have to do it all yourself with shaders. This raises the bar enormously for users of OpenGL, and is a failure of design, IMHO. Furthermore, this was done so that OpenGL drivers for mobile devices could be simpler, but made it harder for new application developers considering using OpenGL for these devices - as well as desktop developers. Again, this is a design failure and confusing what a driver is from an application API - and OpenGL is supposed to be the latter, even if it incorporates elements of the former.

Re:Is it *really* Vulkan?

[zapadnik]

Precisely. IMHO the guys now running OpenGL have confused its purpose - they are more worried about it being a mobile driver implementation rather than the Application API it was intended to be. This is a failure of design on the part of Khronos, and they have doubled-down on this mistake with Vulkan. They prefer to push complexity to application developers rather than those writing the mobile device drivers (who are paid to implement this stuff).

I have pointed out on Slashdot that Vulkan makes application development longer and more error prone. Also, the real-world examples of Apple's Metal and ATI Mantle show that there is not much improvement for desktop GPUs, and the added complexity mostly helps the performance of mobile GPUs where overhead to the weak CPU is significant.

There is an argument that application developers should use another layer over Vulkan - but this seems ridiculous to me as adding another layer removes the supposed benefits of using Vulkan in the first place.

So I agree with you, and it seems the OpenGL/Khronos specs body has now been captured by those oriented towards mobile devices - hence the progression is towards making it easier for the hardware vendors and pushing more work toward the application developers - for little actual gain except on the low-end hardware. This is very bad design, IMHO.

Re:Is it *really* Vulkan?

[Anonymous Coward]

Shaders were introduced in order to remove the complexity of graphics driver maintenance. Application developers kept wanting more and more different options when rendering with multi-texturing, while at the same time they hated the classic OpenGL lighting equation. Register combiners were the original solution to solve this, but they lacked floating point precision. Fragment programs were the next solution, but they required programming in assembly type languages. High level shading languages as fragment shaders were introduced to fix this. Then vertex shaders were introduced to handle matrix blending for skinned models. Geometry shaders were introduced to allow vertices to be deleted and added. Then that led to hull, tessellation and tessellation control shaders.

The original OpenGL ES 1.0 was designed purely with the intention of gaming for the mobile market. They dumped many features because they thought these were "legacy" and wanted to distance themselves from the slower moving CAD/CAM industry (smooth shading, fixed pipeline). Then they had to bring out Open 3.0 to put back many of the features they had taken out, since startups were porting CAD applications to mobile devices. Now that all mobile GPU's are shader based, that's meant that every "serious application" embedded 3D developer now has to make use of GPU programming with shaders. Some are even resorting to going back to using software rendering because they see shaders as just "too fiddly" requiring tweaking of floating-point precision parameters, shader compilation, uniform variable management, and OpenGL error management, all just to render a single quad.

Re:Is it *really* Vulkan?

[zapadnik]

Some people do make this argument. However, if an 'Application Programming Interface' is so close to a 'driver interface' that application developers find it takes too long to produce efficient and robust applications in a timely manner (time-to-market is THE important commercial metric) then this indicates that the API designers got it wrong. Adding lipstick to the pig simply introduces inefficiencies that Vulkan was supposed to remove.

Then we have the real-world benchmarks that show the promised performance gains are not there for higher-end hardware, and it is only helps at the low end (underpowered mobile devices that are CPU-bound, which means the call-overhead affecting the weak CPU is significant). if you are not gaining anything on the desktop and your development time is longer, plus you are back to worrying about specific efficiencies for specific GPUs (because the driver is so thin it cannot work this out for you) then I would say that the design is not useful for application developers (the desktop developers).

OpenGL was relatively easy to pick up and learn. Vulkan will be a much greater learning curve for developers, and will produce LESS efficient applications until the application developers spend a lot of time tweaking their app (Vulkan's main benefit is it exposes enough driver-level concerns that you can do this if you wish).

Adding a layer on top re-introduces the same overhead that Vulkan was supposed to remove. Game Engines indeed help, but that means the game engine developers are now doing the work that driver writers used to - but it is the driver writers who are intimately familiar with every aspect of the hardware.

Vulkan appeals to some - especially those that love TEH NEW SHINEY instead of actually getting very large and complex applications robust and shipped. For me, as a developer creating a high-end desktop application Vulkan's design is a step backwards. I get excellent performance out of OpenGL, but wish to see more effort into improving that instead of wasted on these wild-goose chases that simply make more work for application developers. Apple is the classic case of putting effort into Metal, which hardly anyone uses as it is not cross-platform, instead of moving their OpenGL implementation (which is already half the speed of ATIs on the same hardware [I have a Mac Pro with dual D700s]) from OpenGL 4.1 to 4.5.

Vulkan is supposed to be an API but it is no replacement for OpenGL. IMHO Khronos has made a mistake with this, not because Vulkan is inherently bad, but because resources are limited and putting them into Vulkan just to help low-end hardware means the same resources cannot be used to make cross-platform OpenGL complete better with closed-platform DirectX. In this sense Vulkan is a misstep.

Re:Is it *really* Vulkan?

[zapadnik]

Thanks for posting. I'm interested in where Vulkan may be useful. Are you working on the desktop, or on mobile? Do you have to spend time writing Vulkan code and different execution paths for each of the GPU architectures you deal with? as a desktop application developer I don't have to do this, and the same OpenGL code runs on Mac OS X, Linux, Windows and Android (I'm using JoGL, because the multi-core CPU is only about 10% utilized on four cores; and shader performance on the GPU is the limitation; call overhead is not significant - but time to market definitely is).

So if you care to elaborate on what kinds of problems you are dealing with I'd be most interested. Thanks.

Re:Is it *really* Vulkan?

[Anonymous Coward]

That's why I have a tiny, messy "framework" on top of OpenGL that takes away most of the pain of dealing with OpenGL 3. With it, I can create toy renderers within hours again instead of days like if I had to do it all from scratch. It is not a engine, but a set of helpers that I can use or ignore as my current situation demands. It was totally worth it. Once I fully grok Vulkan I'll create just the same for it.

"Pascal can do"

[Anonymous Coward]

Why did they write it in Pascal? Everything else I read said it wasn't written in Pascal, so why does NVIDEA lie?

Re: "Pascal can do"

[Anonymous Coward]

Bill Gates still loves BASIC. But seriously, I doubt this was programmed in Pascal like NVidea claims.

Re: "Pascal can do"

[Anonymous Coward]

Goto 10

Re: "Pascal can do"

[Anonymous Coward]

And Fortran. Their kind loves Fortran.

Re: "Pascal can do"

[Anonymous Coward]

No, they like FORTRAN and hate Fortran.

Re:"Pascal can do"

[Z80a]

There's no much difference, everything is a clone of Algol or a clone of a clone.
Except lisp.

Re: "Pascal can do"

[Z80a]

To be fair, freebasic is better than java in several performance wise aspects.

Re:"Pascal can do"

[BoogieChile]

Because Pascal is a lot safer than, say C++, because the compiler won't let you shoot yourself in the foot, rather than you ending up bleeding to death because the EMTs can't find you in a heap of 8192 bitwise copies all pointing at each other saying, "That's me, over there."

Re: "Pascal can do"

[TechyImmigrant]

Yes, they really used Oberon

Re: "Pascal can do"

[arbiter1]

AMD is the one that has been Lieing for last few years A LOT more then nvidia, Take that AMD thing outta ya.

Re:"Pascal can do"

[NotInHere]

The EMT's just have to attach you to gdb and then press ctrl-c. Then your state is saved and you can be safely brought to the clinic without any haste.

This trick will win me the nobel prize, I've invented something much better than cryostasis!

Re:"Pascal can do"

[michelcolman]

Pascal has pointers too. And recent versions are object oriented just like C++. There are a few minor differences in the way parameters are passed to subroutines, the way arrays are treated, and the existence of functions within functions, but other than that, is there really that much difference between them when it comes to safety?

I admit it's been almost 20 years since I last wrote something in Pascal, but I don't remember it being that different from C/C++. I had plenty of crashes due to null pointers when programming in Pascal, just like I did in C.

Re: "Pascal can do"

[Anonymous Coward]

You're full of dogshit in your asshole somehow.

Re:"Pascal can do"

[BoogieChile]

Long time to reply, I know, but thought it best to present my complete lack of bona fides and say I've never programmed in either language, but I am familiar with this old joke

Re:They were too chicken to show 4k?

[Anonymous Coward]

You won't be happy until you get yanked into the game and have your ass torn apart by the demons. Then you'll be sorry. Real damned sorry.

sloppy

[PopeRatzo]

The system requirements for the new Doom are ridiculous.

Re:sloppy

[Anonymous Coward]

Wait, if it looks that good in my browser, then why not for reasons would it look good on my PC. What it all the rendering was done over the network, my bandwidth is far better then my video card.

Re:sloppy

[Anonymous Coward]

If you want to stream games bandwidth is not the limiter, latency is. Are you confident that you could get 10ms or lower latency to a game streaming service?

Also, do you really want to pay again and again for the same game? I don't know about you, but I prefer to buy my games so that I can play them when, where and for how long I want.

Re: sloppy

[Anonymous Coward]

Your network bandwidth is better than your video card? So you have like 100 fiber links to your house? Either that or your video card is from the 80's.
I have a cheaper card but it's bandwidth is over 160 GBps.

Re: sloppy

[Some_Llama]

it's because he doesn't know what he is talking about, sure you could render this on a system a mile away and then stream the output to you home computer, but it would still need tobe able to render the 1080p (or higher signal) and the latency would be crazy high. (5/10 seconds?)

Re:sloppy

[Anonymous Coward]

They are?

Minimum:
Intel Core i5 2400 3.1GHz
8GB RAM
Nvidia GeForce GTX 670

Recommend (GD Adjusted):
Core i5 4440 3.1GHz
8GB RAM
Nvidia GeForce GTX 770

That seems pretty modest to me. Even my laptop can more than handle that.

Re:sloppy

[PopeRatzo]

Those aren't the announced specs.

Re:sloppy

[Anonymous Coward]

Yes they are.

https://bethesda.net/#en/events/game/doom-get-ready-to-fight-like-hell/2016/05/05/119

Re:sloppy

[PopeRatzo]

Take another look. The recommended specs are different from the ones you posted.

Windows 7/8.1/10 (64-bit versions); Intel Core i7-3770/AMD FX-8350 or better;
8 GB RAM; 55 GB free HDD space; NVIDIA GTX 970 4GB/AMD Radeon R9 290 4GB or better

Re:sloppy

[Anonymous Coward]

The overinflated recommended requirements aren't the necessary requirements, the minimum is. You never said that you were referring to the absolute maximum settings.

And you should reread what I posted:

Recommend (GD Adjusted)

Which is a much more realistic view of what you will need to run at maximum everything. I have never seen a GD adjusted requirement be wrong.

So again, these aren't unreasonable requirements at all.

Re:Buh-bye DX12

[Z80a]

And make your cellphone battery last more.

Re:Buh-bye DX12

[Bing Tsher E]

drown you in a toilet

There's no need to be vulgar. It will be acceptable for DX12 to be drowned in a bathtub

Re:They were too chicken to show 4k?

[Anonymous Coward]

Well, duh. It's the GeForce 1080, not the GeForce 4K.

Re:when afgans spank you in real life...

[Anonymous Coward]

Well, what can I say, we know how to have a good time. You should try it some time.

Great video.

[LMariachi]

That high-framerate max-everything 1080p footage sure looked impressive shot through someone's phone camera. Nvidia couldn't have provided actual video capture?

Re:Great video.

[allcoolnameswheretak]

The video capturing software would have interfered with the benchmarking. It almost certainly would have eaten up quite a few of those FPS, so if you want to demonstrate raw power, you can't be running video capturing software at the same time.

Re:Great video.

[GNious]

ya, an HDMI splitter + high-end capture-card would have interfered with the rendering....

Re:Great video.

[Shadow99_1]

You know streamers have solved this by using a second PC to capture the video output from the first PC before it's output to a monitor, right? The second PC doesn't even need to be particularly powerful in comparison so sometimes you'll see some pretty old systems being used as 'capture devices'. So really there isn't much excuse for not capturing the feed themselves, other than just not wanting to.

Re:Great video.

[dave420]

It is HotHardware's own video, embedded in HotHardware's article, posted to Slashdot by HotHardware's editor-in-chief (MojoKid). So it has nothing to do with nvidia and everything to do with HotHardware.

Re:Great video.

[Anonymous Coward]

That high-framerate max-everything 1080p footage sure looked impressive shot through someone's phone camera. Nvidia couldn't have provided actual video capture?

'Cause 1080p gaming sounds super exciting...

Re: Great video.

[Anonymous Coward]

So not so hot hardware then (filmed by a phone)

Re:Great video.

[Blaskowicz]

You know GPU vendors have solved that by putting a hardware encoder on the die? ;)

Re:Great video.

[Shadow99_1]

Even with a hardware decoder as part of the GPU's processing ability, to stream or record it takes system resources and so reduces performance somewhat. Hence the comments before mine. Streamers use 'streaming PCs' to reduce this performance hit to nil and optimize the output they can stream. It also lets them do overlays, effects, and other visual alterations with no performance hit as well.

Re:Great video.

[Anonymous Coward]

hurr durr graphics are all that matter! HURRRRRRRRRRRR

Re:Great video.

[LMariachi]

So there was a high-quality source available and HotHardware decided to use a phone instead?

Is there any difference?

[Anonymous Coward]

I watched the video and, quite frankly, I could not see any difference in quality when the card jumped from 60 fps to more than 120 fps.

Re:Is there any difference?

[jandrese]

The cell phone that recorded that video was probably capturing at 30fps, so the quality bump should be undetectable.

Re:Is there any difference?

[Anonymous Coward]

You only need to lower quality to meet certain target of frames per second if your card is not powerful enough, at the same settings increasing FPS yields exactly zero benefits to image quality, just a more fluid motion experience.

Which is particularly important in first person shooters where every millisecond of reaction time is an advantage, but you have to be in front of the monitor and move very quickly the viewport to see any difference. A projector, from afar and recorded with a cellphone? Thats a joke.

Thanks nvidia

[Anonymous Coward]

For showing us what AMD can do.

Vulkan API could bring DirectX to Linux

[Gravis Zero]

one of the big blockers for gaming via WINE has always been DirectX, specifically translating DirectX Graphics to OpenGL. Now with the Vulkan API, we'll be able to implement the various DirectX API versions and OpenGL versions in a completely portable way as function calls to RISC-V GPU code. The only thing left is for someone to make open source firmware that implements the Vulkan API and we'll finally have a truly open source video card.

as for non-gaming, looking over how our desktops are rendered, we should implement a minimalistic window rendering API using the Vulkan API that UI libraries can build upon. this reduces the number of layers involved in rendering and can solve the accelerated vs software only problem via the LLVM implementation that runs RISC-V code. at the same time, the desktop API allowing you to choose a target GPU could forward calls from the remote system to your local system so that the forwarded windows are actually rendered locally which would vastly reduce the bandwidth as well as enable the total integration of multiple desktops.

Vulkan is the rendering API that Linux has needed all along.

Re:Vulkan API could bring DirectX to Linux

[Anonymous Coward]

Music to my ears. We can finally get everyone off of proprietary Windows/MacOS once and for all.

Re:Vulkan API could bring DirectX to Linux

[armanox]

Somehow I disagree - marketing has always been the area that makes all the difference.

Re:Vulkan API could bring DirectX to Linux

[Anonymous Coward]

Music to my ears. We can finally get everyone off of proprietary Windows/MacOS once and for all.

Lennart? Is that you?

Re:Vulkan API could bring DirectX to Linux

[Anonymous Coward]

Sorry but vulkan uses SPIR-V not RISC-V. SPIR-V is an intermediate shading language, RISC-V is an ISA. I don't think they are related.

Re:Vulkan API could bring DirectX to Linux

[Anonymous Coward]

one of the big blockers for gaming via WINE has always been DirectX, specifically translating DirectX Graphics to OpenGL.

One of the big blockers I have seen was always the reliance on unspecified behavior. For example SimCity 2000 relied on specific allocation behavior and when that changed in newer Windows versions Microsoft introduced a fall back mode so SimCity would still work. Another example I personally encountered with Wine is Serious Sam the Second Encounter. It would always blindly take the first entry in a list of available graphics configurations, since that worked on any supported Windows version. On Wine the first entry may not have a depth buffer, perfectly valid since the game did not ask for one, also completely unplayable. Only time will tell how new game engines will fuck around with Vulkan.

Re:Vulkan API could bring DirectX to Linux

[Anonymous Coward]

It's already in Mesa 12.0, but they support only Direct X 9.0c.

Re:Vulkan API could bring DirectX to Linux

[NotInHere]

One of the fears that I have with Vulkan is that it destroys the progress with application isolation that has been inspired by android and other platforms and that is happening on the desktop now as well, look at wayland as an example. One of the red flags was hearing the developers of WebGL say that a web version of Vulkan won't be reasonable because of the missing ability to confine the the applications.

So yes I like low level, but please don't make isolating applications impossible.

Re:Vulkan API could bring DirectX to Linux

[Gravis Zero]

i too worry about security which is why i think you shouldn't let just any program load SPIR-V GPU code. however, isolation still occurs but is dependant on the implementation of the Vulkan API. on the other hand, the desktop rendering scheme i describe is no more dangerous than current rendering systems.

Re:They were too chicken to show 4k?

[adolf]

Well, duh. It's the GeForce 1080, not the GeForce 4K.

I'm not buying one until it's over 9k.

Re:They were too chicken to show 4k?

[sexconker]

Considering how the 980 Ti performs at 4K vs 1080p, I'm not surprised they didn't show anything at 4K.
The 1080 and AMD's Polaris are not the 4K parts you're waiting for.

tech demo

[argStyopa]

Does Doom even make a good tech demo anymore?
I mean, can't pretty much every card do "dark, tight, enclosed spaces, with high-contrast shadows" in their sleep?

Really, the cutting edge in video presentation has to be high-texture details with complex curves in great numbers, massive numbers of moving figures and dynamic lighting in outdoor environments, as well as sightlines - it's always a question of how far you're rendering high details.

Promising gameplay "like the old Dooms" - I *loved* Doom, Doom2 with a passion but since Doom3 and Rage, I can't think of much I'm LESS interested in? I'm pretty thoroughly done with "oh look the lights happened to go out and a wall happened to drop behind me and there happened to be a closet Piranha-like aggressive undead attacking me in the pitch black and I only have 3 shotgun shells left". ZZZZ.

Re:tech demo

[Anonymous Coward]

So you prefer the linear, no exploration, hold-you-by-the-hand, regenerating health, cutscene at every turn style games like CoD. You're a casual gamer. There is no shame in that.

"very reminiscent of previous Doom titles"

[Swampash]

in the sense that it has DOOM in the title, maybe.

Re:"very reminiscent of previous Doom titles"

[Khyber]

It's a rip-off of Brutal doom with double-jump and CoD regen health crap.

I'll stick with real Doom 2. Latest Zandronum mod - Complex Doom Invasion. Pretty fucking slick.

Re:"very reminiscent of previous Doom titles"

[Anonymous Coward]

Regen ? Seriously ?
Even the "Don't hurt me daddy" mode was not like that.

Re:"very reminiscent of previous Doom titles"

[dinfinity]

CoD regen health crap.

Bullshit.

"A combat system known as "push forward combat" is featured, which discourages players from taking cover behind obstacles or resting to regain health. Players instead collect health and armour pick-ups scattered throughout levels, or kill enemies to regain health."

( https://en.wikipedia.org/wiki/... )

Re:"very reminiscent of previous Doom titles"

[hcs_$reboot]

Which version of Doom is that? Doom 3 was not able to handle things like the "guy" does in this video...

Re:"very reminiscent of previous Doom titles"

[Parafilmus]

...CoD regen health crap.

I suspect you weren't paying close attention to the video.

The player healed by picking up medkits and little blue orbs.

The enemies seemed to be dropping a lot of health, but there was never any any regeneration.

Re:"very reminiscent of previous Doom titles"

[StormReaver]

in the sense that it has DOOM in the title, maybe.

Or in the sense that it's yet another first person shooter played in exactly the same way as Doom 1 (run around buildings shooting monsters). The biggest difference is that the visuals are far better. Aside from that, though, it's just like every other iteration of Doom.

Re:"very reminiscent of previous Doom titles"

[dywolf]

REGEN!!?!??!
BLASPHEMY!!

Med kits!
And Blue bottle thingies, laying around.
That's what it needs.

Re:"very reminiscent of previous Doom titles"

[yakumo.unr]

It doesn't use regenerating health.

Re:"very reminiscent of previous Doom titles"

[dywolf]

oh thank Romero.
gave me a panic attack.

Re:"very reminiscent of previous Doom titles"

[Khyber]

I suspect you didn't pay attention to the game's leaked design document.

I tend to follow those before I follow a video, because history has shown time and time gain that what they advertise to you on video is quite often not what you get (Spore, anyone?)

Re:"very reminiscent of previous Doom titles"

[Khyber]

It better not, but that's what's listed in the leaked design document, so you tell me.

Re:"very reminiscent of previous Doom titles"

[Some_Llama]

hmm, in the video the player was clearly picking up health and when the health was showing "Low Health" it did not increase even after standing still for 10 seconds..

Also in regards to jumping, the video showed a low gravity type of jumping response but in no way a double jump.

although this is what i gathered from the video, i also played the demo and it had neither of these.

Re:"very reminiscent of previous Doom titles"

[Some_Llama]

how about did you play the demo? because i did and again you are just saying things that have no bearing in reality when all reality is yelling that you are wrong.

Re:"very reminiscent of previous Doom titles"

[Some_Llama]

You are wrong.

there how's that?

Re:"very reminiscent of previous Doom titles"

[Anonymous Coward]

The multiplayer alpha/beta had double jumping, but it is more useful for jumping from platform to platform over distances than to jump really high.

I haven't seen any form of health regen in the game; enemies do drop ammo/health on a regular basis - more if you do a glory kill (stun enemy - get close and melee), so it really does encourage aggresive play.

Re:"very reminiscent of previous Doom titles"

[Anonymous Coward]

Or in the sense that it's yet another first person shooter played in exactly the same way as Doom 1 (run around buildings shooting monsters). The biggest difference is that the visuals are far better. Aside from that, though, it's just like every other iteration of Doom.

Good. That means it will actually be skill based and fun.

Re:"very reminiscent of previous Doom titles"

[Anonymous Coward]

Design documents aren't static. They evolve during development or else the final product would be a mostly unplayable and unsellable mess. You can't nail every aspect of a reasonably complex game in the first design attempt.

Re:"very reminiscent of previous Doom titles"

[yakumo.unr]

They've been very clear that it doesn't use regenerating health in video interviews, they don't like it, they went for pickups instead, the alphas and betas didn't use regenerating health, and the single player footage that's been on twitch and youtube just days before release has clearly shown it's not in use too.

Re:"very reminiscent of previous Doom titles"

[Anonymous Coward]

Citation needed, especially one that is dated and verified. Because nothing is backing you up.

Summary

[Swampash]

Video hardware achieves high framerate when gameplay takes place indoors in a single room with some platforms and a handful of monsters.

Re:Summary

[Anonymous Coward]

And ignores the fact that framerate will drop on a significant number of games that are doing interesting things that GPUs do not handle.

Admittedly, there's no good way around this - you can't knock a card for shit frame rates on a CPU-bound game; but it's largely why "hurr framerate" is often a dumb metric when discussing gaming hardware.

Re:Summary

[Anonymous Coward]

And is then written up in a twofer shill story for Nvidia and ID Software (is that a first for Hot Hardware aka Shill central?)

And finally, MojoKid, owner and operator of HotHardware, gets yet another slashvertisement posted. He collects his paycheck from Nvidia and ID and can now afford ramen for dinner tonight.

They're not that bad at all

[rsilvergun]

It'll run find on an 8320 and a $150 gpu. The only reason you can't run it on an i3 is they're dual core and it uses the actual core. I could play doom 3 on $500 worth of hardware. Or just play it on the PS4 for $300. And give it a year after launch after it's been optimized and I'll be it'll run on my 4 year old 5800k and 2 year old 660 gtx.

Re:They're not that bad at all

[Khyber]

"I could play doom 3 on $500 worth of hardware."

You're doing it wrong. You can run D3 maxed the fuck out on a P4, 1GB RAM, and a midrange 512MB GeForce 5 or 6.

You'd barely break past $100.

Re:They're not that bad at all

[PopeRatzo]

It'll run find on an 8320

But not on an i5-750.

Re:They're not that bad at all

[Coren22]

Wow, that is crazy high specs for Doom 2, you could run that on a Pentium 1 75 mhz, you could probably even find one for free on craigslist.

Re:Buh-bye DX12

[Anonymous Coward]

I must have struck a nerve with someone with mod points who has had their lunch eaten and their wife fucked by other men. Probably a Microsoft shill.

1050 and 1040

[Michael Woodhams]

I like my computers very quiet, so my rule of thumb (sometimes violated) is buy the best GPU available which is passively cooled and needs no extra power connector.

I only found one page about the GTX 1050 or GTX 1040. This gives expected release date 2016Q3. However they don't give power consumption (critical for my purposes - I'd be looking for a maximum of about 60W) nor do the numbers they quote give me much idea of how much faster it will be than (say) a GTX 750, which so far as I know is the current best quiet GPU.

Re:1050 and 1040

[Michael Woodhams]

With a bit more research:
Compared to 1080, 1050 has 2/5 as many cores and about 5/8 the clock speed. 1080 has design thermal power of 180W. I don't remember if power is proportional to clock, but if it is, 1050 should have about 1/4 the power draw of a 1080, which puts it at 45W which won't require a power connector and is easy to passively cool, but possibly passive cards won't be available at launch. 1040 would be about 28W (expect fanless to be the norm), and 1060 about 62W (where a power connector might be required, and we might eventually get passive cooling but not real soon.)

If power is a higher power of clock (eg. clock speed squared) then the numbers get even better.

Re:1050 and 1040

[evilbessie]

Really you should be caring about 75W as that is what a PCIex16 can supply. The 750 was 71W IIRC and is still the most powerful non-powered card I've seen. There was nothing in the 900 series which replaced this so I would guess that this will be coming, as would an update of the 730 for SFF/low profile uses (25/35W).

Re:They were too chicken to show 4k?

[trabby]

I have a broken 9600GT that I could sell you.

lol

[Anonymous Coward]

a few minutes in, at the 00.53 mark

Re:They were too chicken to show 4k?

[JaredOfEuropa]

Even so, 1080 is an odd name. It's a bit like selling an SD video device with the word "VHS" in the name... in a Blu-ray era. Even most larger low end displays are running at a vertical resolution of 1200 these days.

Not impressive.

[ledow]

Given what kind of a stunned sloth the demo ran on my machine that's either:

a) impressive.
b) indication that they optimised it and ran it on a half-decent machine.

I can't say I'm that impressed. 1000 fps, yeah, THAT'S one hell of a piece of hardware and worthy of an article.

But that an in-production game runs at 60fps vsynced 120 without at 1080p (which isn't actually that high a resolution guys, welcome to 1999) on the top-of-the-line unreleased hardware? Well, I'd bloody hope so. Or else nothing else would work and the game developers aren't even trying to push boundaries.

Call me when it can do 4K at that kind of speed.

Re:Not impressive.

[Anonymous Coward]

I ran an old tech demo on my 760 that hit ~1200 fps, there was an audible tone coming from the card that varied pitch with the framerate.

No 4k

[Anonymous Coward]

So, with respect to that fillrate, we cannot obtain 4k, 60FPS. Much shame for the PC master.

Re:They were too chicken to show 4k?

[evilbessie]

Where is your evidence for this?

My experience is that everything has stopped at 1920x1080 as these are the panels required for TVs, it's very difficult to get 16x10 aspect ratio displays anywhere. With the larger number of 4k displays (also 16x9 aspect) I don't know where you think these x1200 monitors are coming from.

Re:They were too chicken to show 4k?

[thsths]

Exactly my thought. So the latest and greatest is able to run 1080p in at least 120Hz, which is nice. But can it do 2160p in 60Hz? Probably not, because that would mean pushing twice as many pixels. It may also struggle to provide decent VR (2x 1080p with at least 90Hz).

Lighting

[Anonymous Coward]

Good, maybe they can use some of that extra processing power for lighting. Adding millions of extra triangles and materials doesn't matter at all if the lighting is unrealistic and flat. Bad lighting sucks the atmosphere out of a game no matter whatever other graphical assets you use.

Re:Lighting

[Blaskowicz]

Naturally it's the most power hungry, compute hungry issue. If you want really good lighting or god forbid shadows it might need one hour per frame to render, whereas we'd rather have it take 10 ms.
Id went to more static lighting with Rage. Although even Doom 3 lacked dynamic lighting for every imp fire shot and plasma gun shot.

Re: They were too chicken to show 4k?

[jsh1972]

You mean 4 times the pixels? It doubles in the horizontal as well.

Re: They were too chicken to show 4k?

[Anonymous Coward]

1080p at 120hz vs 2160p at 60hz. 4x the pixels per frame, 2x the pixels per second.

Re:They were too chicken to show 4k?

[Stele]

I'm waiting for the GeForce 640K. That should surely be enough for anybody.

Publish real benchmarks already.

[Anonymous Coward]

If Nvidia would like to impress me they would release standard benchmarks so I can see handy bar graphs comparing its performance to existing cards.

But they haven't. All they have released are hand wavy BS buzz words.

Of course it gets 170 fps

[Torp]

It's a shitty console port and all the graphics decisions are based on what the PS4/XB1 have inside.
Of course it's going to run into the thousands of fps on a video card that costs as much as the whole console.
Oh wait. It only got 170. For some reason...

Re:Of course it gets 170 fps

[zlives]

umm if its like any new flagshipVC it will cost almost twice a playbox

Why exactly...

[Grim Beefer]

...are there two "news" stories about a new Nvidia card? Didn't ya'll just post about the unveiling of the card? Why do we need a follow-up story, when someone plays a new game on it? That seems less than newsworthy...I'm not saying that we've got paid articles being posted....but something doesn't smell right...

Hitting The Sweet Spot

[ytene]

It would be nice if it were something that nVidia were actually working towards (which I don't think they are, btw), but wouldn't it be nice if the various generations of nVidia GPUs were designed to sit a set of pre-defined targets for thermal output and power consumption?

Hang on, I get the fact that innovation doesn't come to order, but stay with me a little longer...

In top end systems these days [those for which things like the 1080 are relevant] the GPU [or plural for SLI configurations] draw the most power and put out the most heat. Like many gamers, I'm going to be tempted to upgrade my existing GPU [which in my case in a 980GTX] for the 1080 once I can get my hands on a warrantied, water-cooled model... But for me, the real challenge is actually driven more by ensuring that the power consumption and TDP profiles of the new card fall within the capabilities of the rest of my gaming rig.

This time around it looks as though I am in luck: the 1080 seems to be around 180W TDP, 5 less than my 980...

We could easily argue that the gamer market doesn't really care about this: the advent of the 1080 is an excuse to throw away half the innards of your gaming PC and build anew. But that could easily make this a non-starter for many who are gaming on a fixed or controlled budget. I can comfortably stretch to the cost of a replacement, water-cooled 1080 card, but the truth is that in order to take something that runs hotter (like a Titan X, for example) would require that I swap my existing (dedicated) triple radiator for say a quad, or a pair of doubles, or maybe even more. That, in turn, would require a new case. which might have other knock-on implications.

But by sticking at the ~ 180W mark, hopefully nVidia will allow me to swap GPUs with nothing more complicated than re-running replacement lengths of connector tubing, and flushing the rest of that cooling circuit.

So granted there's no hard-and-fast rule here, but what's more useful - extracting the last Hz of performance, or releasing cards that have performance profiles that we can "predict" and build around? Would you rather pimp out for the ultimate [and be willing to pay more for it] or does the convenience of a plug-compatible performance upgrade make more sense?

Re:They were too chicken to show 4k?

[zlives]

in this particular case of resolution... that would be way over kill/

Re:They were too chicken to show 4k?

[Anonymous Coward]

How is it an odd name? It falls perfectly in line with Nvidia's current naming convention (ex. 280, 480, 680, 780, 880M, 980, 1080).

Re:They were too chicken to show 4k?

[Anonymous Coward]

Nvidia's drivers... horrible? Are you sure you mean Nvidia and not ATI? Cuz I'm not sure what the fuck you are talking about. I'd be willing to bet most people here agree with me, too.

Besides that, I don't think these big companies really care about catering to the "elite" gaming community anymore. Self-inflated ego aside, your numbers are small and I'm sure they make a much, much larger profit on the mid-range hardware they sell. Also, you're fat, you smell bad, and nobody wants to deal with you and your shitty entitled attitude.

Re:They were too chicken to show 4k?

[Anonymous Coward]

In case you want to know where to get non-16:9 displays, Eizo sells 16:9, 16:10, 4:3, 5:4 and even a square 1:1.

I'd personally like a 3:2 monitor, but they don't seem to exist this decade. Some laptops used to have one.

Re:They were too chicken to show 4k?

[Blaskowicz]

Higher refresh rate is always a benefit even if your hardware is a bit slow, old or low end. You get lower latency, less tearing or when you get tearing it's less severe. So if you're after gaming performance a 1080p 144Hz screen is great. For really high end there's 2560x1440 144Hz, if you buy a 2160p 60Hz you're a sucker (or maybe not, as it may be actually cheaper)

What sucks is the market is so much oriented toward consolidation and high volumes, the options are few for high refresh monitors. So you can't get a 1600x900 at 120 or 144Hz to game with a low cost GPU or even an APU, or same with IPS panel. You can't get a 1920x1200 at 120Hz or one bigger than 24".

High refresh has been kept as a differentiator on high margin displays.