Slashdot Mirror
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.
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.
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.
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.
And make your cellphone battery last more.
There's no much difference, everything is a clone of Algol or a clone of a clone.
Except lisp.
To be fair, freebasic is better than java in several performance wise aspects.
Well, duh. It's the GeForce 1080, not the GeForce 4K.
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."
That high-framerate max-everything 1080p footage sure looked impressive shot through someone's phone camera. Nvidia couldn't have provided actual video capture?
Yes, they really used Oberon
I should use this sig to advertise my book ISBN-13 : 978-1501515132.
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.
Anons need not reply. Questions end with a question mark.
AMD is the one that has been Lieing for last few years A LOT more then nvidia, Take that AMD thing outta ya.
I'm not buying one until it's over 9k.
Kid-proof tablet..
The cell phone that recorded that video was probably capturing at 30fps, so the quality bump should be undetectable.
I read the internet for the articles.
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.
in the sense that it has DOOM in the title, maybe.
Video hardware achieves high framerate when gameplay takes place indoors in a single room with some platforms and a handful of monsters.
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.
Hi! I make Firefox Plug-ins. Check 'em out @ https://addons.mozilla.org/en-US/firefox/addon/youtube-mp3-podcaster/
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).
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.
Quattuor res in hoc mundo sanctae sunt: libri, liberi, libertas et liberalitas.
I have a broken 9600GT that I could sell you.
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.
If construction was anything like programming, an incorrectly fitted lock would bring down the entire building...
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.
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.
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.
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.
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).
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!
You mean 4 times the pixels? It doubles in the horizontal as well.
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.
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?
> 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(), // for each uniform in each shader
* glShaderSource(),
* glCompileShader(),
* glAttachShader(),
* glLinkProgram(),
* glGetUniformLocation()
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.
I'm waiting for the GeForce 640K. That should surely be enough for anybody.
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?)
...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...
> 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.
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.
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.
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?
in this particular case of resolution... that would be way over kill/
> 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.
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.
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.
Those aren't the announced specs.
You are welcome on my lawn.
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.
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.
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.
umm if its like any new flagshipVC it will cost almost twice a playbox
Take another look. The recommended specs are different from the ones you posted.
You are welcome on my lawn.
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.
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