Jump to content

  • Log In with Google      Sign In   
  • Create Account

Promit

Member Since 29 Jul 2001
Online Last Active Today, 08:12 AM

#5221974 SPIR-V Macro Compiling

Posted by Promit on 07 April 2015 - 08:09 PM

There's no runtime conditional compilation stuff in SPIR-V. You would create all variants, or use static/uniform/coherent branching to select. 




#5221423 Vertices and indices in the same buffer?

Posted by Promit on 04 April 2015 - 07:50 PM


@Promit: I may very well be reading incorrectly between the lines, but I get the impression that mixing different kinds of data in single buffer (in old or current GL or D3D anyway) is not something you've done or seen done, at least enough to be a somewhat common pattern?

Correct, but that's not to suggest there's any issue with it. I've just never seen any of the documentation from the IHVs suggest that you should do it, so it never really crossed my mind to try it. I think it's a good idea if GPU memory fragmentation is a concern. 

 

This was a few years ago: https://developer.nvidia.com/sites/default/files/akamai/gamedev/files/gdc12/Efficient_Buffer_Management_McDonald.pdf




#5221409 unethical

Posted by Promit on 04 April 2015 - 06:17 PM

If other members of both projects are aware and okay with it, obviously not. If other members are not aware and it doesn't interfere, probably not. If you're not being paid anyway, probably not.

 

If they're aware of it and express a problem with it, maybe.




#5221367 Vertices and indices in the same buffer?

Posted by Promit on 04 April 2015 - 12:26 PM

Back in the day, GPUs weren't actually able to read indices from GPU memory. They were always streamed from main memory. But that is ancient history. Nowadays, on at least some hardware, I've heard that uniform buffers, texture buffers, and possibly shader storage buffers get special handling. The glBufferStorage API (which you should be using, not BufferData) requires you to pick a specific buffer type, not a mask. However on closer reading this appears to be simply a question of the buffer's binding point, not anything to do with the actual usage (which doesn't kick in until BindBuffer). I don't see anything offhand that says you can't bind the same buffer to more than one binding point, and from there it's just a question of offsets.

 

So yeah, go for it. I would be inclined to keep constant/uniform buffers and texture buffers separate from everything else, though.




#5221244 Safe endian macro

Posted by Promit on 04 April 2015 - 12:48 AM

An M68k? Sparc? The freaking HPPA?? What on earth are you coding that requires this level of flexibility? (If it's a generic header for 'everything', stop and do something else that is grounded in reality.)




#5221146 SetTexture question

Posted by Promit on 03 April 2015 - 11:18 AM


in performance costs, apparently the state changes from most to least expensive are:
1. textures
2. meshes
3. materials
4. projection matrix
5. world matrix
6. other state changes like cull on/off, etc.
 
which means you want sort your render queue on texture, then mesh, then material, then near to far.

Maybe in 2005 - not so much today.

 

A modern day GPU is a very different creature from the devices for which D3D 9 and even 10 were developed. The older advice on performance is almost totally irrelevant. Ultimately there are just a few categories of state changes that make any difference:
- Total GPU flush changes. In most cases this is an RT switch.

- Shader changes.

- Pipeline reconfiguration. This can include some of your rasterizer states, depth stencil settings, and blend settings. On some GPUs, changing these states to unexpected values will trigger shader recompiles.

 

Note what's NOT on the list: buffer changes, shader constant changes (which are buffers now), texture changes. (Texture format changes may have an impact; it depends on the situation.) The GPU doesn't care at all about binding different resources to the pipeline, because all of these things are now flowing through virtualized memory.

 

Oh and when you change one pipeline state, you may as well change all of the pipeline states. It's the same thing. Changing anything will trigger validation of the pipeline against the current shader and potentially the current RT. Clever sorting serves no purpose. Avoiding duplicate changes is only useful if it allows you to avoid setting an entire state block, or ideally changing state at all. (May be hw dependent.)

 

Lastly, all state is validated at draw call time. If you change state, basically the driver sets some dirty bits (so it knows how much validation is needed later) and records the new state in a table. It doesn't care whether you issue one change or a hundred. Desktop drivers usually detect duplicate changes, but mobile drivers may not. Be aware of what impact patterns like: SetTexture(A); SetTexture(B); SetTexture(A); may have in setting dirty bits even if the change is ultimately redundant.




#5220542 What will happen with OpenGL after Vulkan?

Posted by Promit on 31 March 2015 - 12:56 PM

Public statements by Khronos so far indicate that OpenGL development will continue. There is a lot of momentum in GL, which is what screwed previous attempts to revise it. This time, they are offering both.

Personally I despise GL. It's horrible to work in. So I am chomping at the bit to change over.


#5220013 No matching overloaded function found: mix

Posted by Promit on 29 March 2015 - 01:23 PM

Looking at the docs, I don't think mix is defined for matrix interpolation at all. You might want to write up a custom function for it.




#5219457 Direct3D 12 documentation is now public

Posted by Promit on 26 March 2015 - 03:57 PM


I would not be surprised if MS decided to roundhouse kick the reference driver...

Don't know - the reference driver may be more useful on the driver side. Remember it's a reference, not a generic soft rast. It exists to be a stable basis of comparison.




#5219384 SLI with an advanced OpenGL game?

Posted by Promit on 26 March 2015 - 12:13 PM

Heh, yeah. Doing SLI or Crossfire on your own is a nightmare. The GL API doesn't help at all.

Here's the situation: you cannot debug it. Some of NVIDIA's performance tools (NSight) might help but sometimes these things blow up or fail to give productive results in GL. Basically, something in your code is shutting off SLI or breaking it. It might be a bad Map or BufferData. It might be an extension that isn't supported.

The way to find it is to throw an FPS counter in, and then shut off the entire pipeline. Then start bringing phases of the render back in, until you find which piece breaks the speed up. It's going to be boring and time consuming, and the offending call may not make any sense when looking from outside the driver. Good luck.


#5219237 Direct3D 12 documentation is now public

Posted by Promit on 26 March 2015 - 12:11 AM

Have fun!

https://msdn.microsoft.com/en-us/library/windows/desktop/dn899121(v=vs.85).aspx

 

P.S. Yes, SlimDX will be supporting D3D 12. We're going to build a modern version of the library that is streamlined to 12 + utilities/math only, and supporting all Win10/D3D 12 hardware platforms. It will be slick.




#5218941 should i learn how to work with a 3d modelling software?

Posted by Promit on 24 March 2015 - 06:25 PM

You don't need to master 3d art creation. You SHOULD learn to do it. It's part of the process, and it's myopic to imagine a game as a program blindly consuming art assets that appeared by magic. Understanding what is involved will give you greater perspective on how to design for it, what issues can be created or fixed by engine design decisions, and what possibilities there are for inputs to your game code. It's also quite useful to be able to create your own test assets that are built a particular way, especially when you and the artist aren't getting tools and game to match properly.


#5218936 Any good cross platform C++ scheduler libraries?

Posted by Promit on 24 March 2015 - 06:15 PM

I need something like this too, but with mobile support (iOS at least). TBB unfortunately doesn't have official IOS support and I am wary of random ports. I looked at libdispatch last year, which isn't exactly a task system but includes enough of the right ingredients to finish the job. I should check and see how their various OS ports are doing.


#5218531 Efficient way to check which lights belong to which meshes?

Posted by Promit on 23 March 2015 - 12:01 PM

Twenty lights and a couple hundred objects? Brute force sphere-sphere testing should be nearly instant in this case. You're doing something wrong there.




#5218477 what do you use to document your c++ code?

Posted by Promit on 23 March 2015 - 09:33 AM


I've usually used Doxygen in my own projects... but, on every professional game team that I've ever worked on, there's been usually no code documentation... and it's often not that bad!
Sometimes wikis are used, but they often become outdated, and wrong/outdated documentation is worse than none. Same goes for doxygen/etc comments...

Yep, same here. There's usually a wiki that drifts, and really only exists for the new hires to get some clue of how things were set up originally. After that, it's all about learning your way around the system.

 

Different for actual engines in regular use across wide groups of people, though, or other middleware projects. You don't get to skimp on the documentation there... for SlimDX we used the built in VS doc system but through Sandcastle with a custom front end bolted on. For pure C++ I'd just use Doxygen, but I'd only bother for public APIs.






PARTNERS