Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 06 Jun 2010
Offline Last Active Today, 06:55 AM

Posts I've Made

In Topic: Next Generation OpenGL

Today, 06:55 AM

Question: why do we suddenly need, in 2014, much closer access to hardware? When hardware has been getting faster at a crazy rate and phones have the same 3D power as gaming rigs used to, why did someone decide "we need a few percent more by completely redesigning all the drivers and APIs"?


If this was happening 10 years ago it would make sense to me, but these days we have such an abundance of GPU power and it is increasing faster than you can keep up!


We don't "suddenly need" it in 2014, we've needed it for quite some time longer now; 2014 just happens to be the year when the APIs, hardware vendors and developers are all coming around to the same kind of thinking (it could have been any year, it just happens to be this year).


Previously there have been other solutions to the problem of API overhead - batching, instancing, primitive restart, texture arrays, draw indirect, etc - but those solutions have their own limitations and have been pushed pretty much as far as they can go.  The new APIs just solve the same problems that these other solutions solve, but in a more general and more useful way.

In Topic: Is the BIOS Serial Number Always Set, Constant & Reliable

Yesterday, 07:15 AM

This kind of scheme is also going to fail if your user gets a new PC.


Why not use a third-party authentication provider instead of trying to roll your own?

In Topic: problem in resizing the swapchain buffers

Yesterday, 06:08 AM

First problem I can see is that you should release your stuff before calling ResizeBuffers, not after.  See http://msdn.microsoft.com/en-us/library/windows/desktop/bb174577%28v=vs.85%29.aspx



You can't resize a swap chain unless you release all outstanding references to its back buffers. You must release all of its direct and indirect references on the back buffers in order for ResizeBuffers to succeed.


Calling ID3D11DeviceContext::ClearState is also advisable to ensure that everything that needs to be cleared out is cleared out.


Get those right first and see if your problem continues, then post an update please.

In Topic: Using old array or stl

19 August 2014 - 06:56 PM

For storing float vertices the answer is neither.

In Topic: Ubuntu + Performance

19 August 2014 - 05:12 PM

...Does this sound like a good move?


I'd consider it a toss-up.


Offloading the desktop environment to the GPU makes a lot of sense, because otherwise it's going to tax the CPU.  For performance of the OS itself you obviously want to keep CPU headroom for number-crunching and other such work, so having the GPU handle display tasks can actually make your OS faster.


Raymond Chen has a good writeup of this for Windows here: http://blogs.msdn.com/b/oldnewthing/archive/2013/03/27/10405554.aspx and it's worth quoting as it will apply to other compositing desktop environments too:


Starting in Windows Vista, a lot of visual effects were offloaded to the graphics card. Consequently, the impact on system performance for those visual effects is negligible, and sometimes turning off the effect actually makes your system run slower because you disabled hardware acceleration, forcing operations to be performed in software.


For gaming, any desktop worth using is going to switch itself off when you go fullscreen - worst case is that it's going to keep a few MB of buffers hanging around, but it's not going to be compositing in the background behind a fullscreen game.


So rather than making a judgement based on what seems the "lightest" desktop (which may well give you a slower OS as you may end up losing hardware acceleration) you should make a judgement based on whether or not it has these performance characteristics I mention.  Does it satisfactorily offload to the GPU in normal usage?  And does it switch itself off when you go fullscreen in a game?