Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

The article fails to mention that the graphics quality of the games made for these consoles could be a lot more advanced than what's available for the PC then, because developers get to write games directly for that specific hardware. John Carmack has said that the DirectX/OpenGL layers can slow down performance by 4x-10x, for example.


Is it really that much? I guess abstraction comes at a big performance cost.


You'll have to forgive my skepticism, but can you link to where John Carmack has ever made such a statement?

What I don't understand is, if the performance is being slowed by 4x to 10x, what is it being compared to? I doubt anyone is actually coding GPU assembler for complex 3D scenes all the big games require. If there are no alternatives to these API's for allowing game devs to create the results they need, then its a lot like comparing apples to oranges.


John Carmack: So we don't work directly with DX 11 but from the people that I talk with that are working with that, they (say) it might [have] some improvements, but it is still quite a thick layer of stuff between you and the hardware. NVIDIA has done some direct hardware address implementations where you can bypass most of the OpenGL overhead, and other ways to bypass some of the hidden state of OpenGL. Those things are good and useful, but what I most want to see is direct surfacing of the memory. It’s all memory there at some point, and the worst thing that kills Rage on the PC is texture updates. Where on the consoles we just say “we are going to update this one pixel here,” we just store it there as a pointer. On the PC it has to go through the massive texture update routine, and it takes tens of thousands of times [longer] if you just want to update one little piece. You start to advertise that overhead when you start to update larger blocks of textures, and AMD actually went and implemented a multi-texture update specifically for id Tech 5 so you can bash up and eliminate some of the overhead by saying “I need to update these 50 small things here,” but still it’s very inefficient. So I’m hoping that as we look forward, especially with Intel integrated graphics [where] it is the main memory, there is no reason we shouldn't be looking at that. With AMD and NVIDIA there's still issues of different memory banking arrangements and complicated things that they hide in their drivers, but we are moving towards integrated memory on a lot of things. I hope we wind up being able to say "give me a pointer, give me a pitch, give me a swizzle format," and let me do things managing it with fences myself and we'll be able to do a better job.

http://www.pcper.com/reviews/Editorial/John-Carmack-Intervie...


Yes, in layman's terms - on the console you talk to the hardware as your buddy, you trust each other, and get along doing business better.

On OS's, there is no buddy, friendship. The OS (kernel) does not trust you by default, and there is no friendly language to get quickly the stuff done as in the consoles.

You can't schedule a DMA user-space. You can't batch too many draw calls in one piece. You can't check, inspect more detailed what the system is doing. You can't talk to any of the devices directly, but have to delegate this through the OS.

Now, the consoles have gotten to be closer and "less" friendly in that respect. But then again, security becomes much more important these days, especially with online games...


The newest Nvidia stuff is offering some of that, though it may be specific to CUDA.

The thing is, the bandwidth mismatch between the GPU and its memory and the PC memory to GPU memory is crazy. There seems to be extra latency involved there too.

As long as we plug a special-purpose video card into an expansion bus, I suspect the best performance will come from manually-scheduled transfers.


Why can't you use cuda / opencl to force updates on specific video memory?

I guess trying to mix directx / opengl and cuda / opencl would be a pain. One is at a completely different abstraction layer than the other.


Not to mention that I don't know of any GPU manufacturer that releases any of that super-low-level information.


ATI/AMD has released GPU programming manuals and open-source drivers, so presumably the information is out there.


I could be wrong about the open source drivers, but last time I looked into it (about two years ago), the lowest level interface was still a binary blob on top of which the open source driver sat.

As for programming manuals, any of the really low level ones I've seen are about 4 years old now. If you know of any up-to-date ones, I'd love to see them out of personal interest, but I've yet to find any myself.



Thanks!




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: