Jump to content

  • Log In with Google      Sign In   
  • Create Account

Banner advertising on our site currently available from just $5!

1. Learn about the promo. 2. Sign up for GDNet+. 3. Set up your advert!


Member Since 29 Jul 2001
Offline Last Active Yesterday, 11:39 PM

#5181817 GPU Particle Update

Posted by Promit on 20 September 2014 - 10:27 PM

It's probably better to have one compute shader that does everything, possibly with conditional compilation if needed. The old "ubershader" approach, basically.

#5180881 How do work at home game developer jobs work

Posted by Promit on 16 September 2014 - 08:09 PM

The times I've seen work at home game developers in the professional arena are:

1) Startups who don't have a choice and indeed may not have an office in the first place

2) Situations where a current high level employee decides to relocate and the company really, really values that engineer

3) People who have a lot (think 20 years) of industry experience and are highly valued. These are usually contract positions, not full time

4) Other, misc short term contracting deals - usually through industry experience and strong contacts


You do NOT just go out and get a remote job.


That said, usually VPN and the necessary equipment at home solves the problem you asked about nicely.

#5180756 I want to be a graphics programmer. Am I on the right path?

Posted by Promit on 16 September 2014 - 11:12 AM


Yes on that count as well. There are a lot of SIGGRAPH proceedings worth reading, as well as tons of hardware and platform documentation released by NV and AMD.

Do you have any download links to the SIGGRAPH proceedings?


Ke-Sen Huang's page is the massive archive: http://kesen.realtimerendering.com/

But a more focused place to start is the Physically Based Shading courses: http://blog.selfshadow.com/publications/

Most of SelfShadow's blogroll is also extremely high quality reading material from people who are not only skilled and knowledgeable, but also highly reachable (typically through twitter).

#5180366 I want to be a graphics programmer. Am I on the right path?

Posted by Promit on 14 September 2014 - 08:34 PM

Do people actually read a gigantic stack of books to become a pro at this?

Yes, but it's not sufficient.

Or is it better to skim the books and work on graphics demos that build your knowledge over time, only diving into the stack of books when necessary?

Yes on that count as well. There are a lot of SIGGRAPH proceedings worth reading, as well as tons of hardware and platform documentation released by NV and AMD.


Ultimately however, collecting knowledge without context or application serves no purpose. The high quality people in this industry don't learn by reading, they learn by doing. Reading is a useful way to fill in holes and compare notes with those who are more knowledgeable, as are communities. These are most effective when you are actually in the process of building a full blown rendering system, and can contextualize the information.

#5180019 LOD in modern games

Posted by Promit on 13 September 2014 - 12:56 AM

In the general case, hand done LODs of models at three or four distances, maybe plus an impostor billboard of needed. Simple alpha fade between them. Nobody is bothering with continuous LOD or other automated systems, as they have several flaws:

* Expensive on CPU

* Require dynamic GPU buffers

* Pretty much ruin any chance of instancing/batching - this is a huge problem

* The vast majority of methods are not able to cope with tex coords, normals, tangent spaces, and all the other real world stuff verts actually use. This becomes a huge n-dim optimization problem.

* In conjunction with the above, LOD changes create severe popping artifacts due to discontinuities in the various spaces

* Vertex processing isn't the limiting factor in nearly every system


The primary use of LOD right now is to prevent small triangles from being rasterized. Rasterization of tiny (less than 8x8 pixels in particular) triangles is catastrophically slow on modern hardware and negatively impacts overall fragment shading efficiency. There are a few special cases where more sophisticated LOD techniques are useful, notably (and almost exclusively) terrain.

#5179791 Can concave polygons be used in pathfinding?

Posted by Promit on 12 September 2014 - 01:23 AM

It's called convex decomposition, and apparently there are quite a few papers on the topic. Most are probably more complex than what you need.

#5179790 Which algorithm is more efficient for visibility culling? BSP or OCTree?

Posted by Promit on 12 September 2014 - 01:19 AM

I would start with the venerable kD tree.

#5179777 1D and 3D textures useless?

Posted by Promit on 11 September 2014 - 11:54 PM

I know I can create my own organization, but as I said I want it to be exactly as a 3D texture because maybe it will have the same performance optimizations.

Don't count on it. The graphics driver will reshape your textures into different memory layouts that tend to favor the underlying hardware and things like cache locality. This blog post actually has a very nice summary:


Although it doesn't discuss what the driver/hardware does with 3D textures. (The driver may just treat 3D as a stack of 2D. Not sure.)

#5179765 best way to make game render most efficient

Posted by Promit on 11 September 2014 - 10:45 PM

There are essentially three things that allow a developer to build a game that renders very efficiently:

1) Understand the underlying hardware (GPU and system architecture) and software (driver and API) in detail. The more detail the better. Think incredibly detailed. The best graphics developers have most likely worked for AMD or NVIDIA, or very closely with those companies.

2) Understand the structure of the game's rendering pipeline in detail. This means ALL of the draw calls being issued per frame, what inefficiencies exist, what timings look like, where stalls occur, etc.

3) Understand how to analyze, test, and modify the game with the knowledge of (1) and (2) to fine tune the balance between all the pieces of a renderer and its interaction with the underlying systems.


These things were never easy, but I'll argue that they've become increasingly more challenging over the last thirty years, to the point that it requires intense dedication and competence from the working programmers in the field. I'd also argue that even among the people doing this job, only a subset are really good at it. 


Personally I prefer to work from the architectural side. I feel like benchmarking and testing is all working in the dark if you don't know anything about the hardware or driver. So I start by reading all the published documentation about graphics performance on my target platform. There's generally plenty to read, though it can take some digging to find. People around this forum know where to find it if needed. That alone will generally give you a first round of ideas about what to fix and change in code. The specific things you asked for are unanswerable, because all of these performance issues interact with each other in ways that are not easy to understand or explain without understanding the underlying systems. 


There are some papers that apply fairly universally and should be read by everyone. This in particular comes to mind:


Some performance advice is more ephemeral and comes mostly from talking to the right person about the right things. For example, modern GPUs hate shading small triangles; pixel shader execution efficiency will plummet. This will initially look like a poly count problem but it's not. These kinds of things are picked up by doing this work for a long time and understanding the hardware; I've never seen a good summary of everything in a single place.

#5179206 Indie game developers getting screwed by PAX?

Posted by Promit on 09 September 2014 - 07:07 PM

It appears that the OP is at least quite close to the company in question. It's not the first time (s)he has linked their blog, and in the same spammy way across multiple forums.

#5178461 GOTO, why are you adverse to using it

Posted by Promit on 06 September 2014 - 01:45 AM

BREAK and CONTINUE   can be less clear where there are (many) nested loops  or where your   'just jump your eyes'   might be to along ways off the screen far below.

Which is why well written code doesn't do that either. It's a false duality. Goto doesn't excuse other ways of writing shitty, hard to follow code.




GOTOs can flatten out/clarify certain patterns of code which otherwise would be a mess of nestings and escape logic (and not just for error recovery/handling)

This is certainly the case in C or code that is forced to follow similar flow patterns, where a jump to a cleanup stage is often required in lieu of a return. The RAII crowd will claim that this is a fundamental failing of the language. I have mixed feelings on the matter, but it's the damndest thing: hundreds of thousands of lines in our current project, a number of subroutines in the thousands of lines, and no need for goto statements. So I can't really agree with you that its use is a common structural pattern, particularly in situations where you do use RAII constructs (ie locally scoped destructors) to deal with cleanup.


Here's the thing, though. Maybe it's goto. Maybe it's a break/continue on deeply nested looping structures (which we definitely have in our codebase). It sorta doesn't matter which one - most of these direct-jump commands are representative of fundamental design issues, or simple poor code quality in need of refactoring. You've got a big attitude about the wrong thing. If you have a lot of non-local control flow, especially nested, then your code sucks. Avoiding a specific keyword has no effect on that. These are endemic problems. If your use of goto makes completely badly written code only tolerably badly written, that is not an argument in favor of goto, nor is it an argument in favor of other long distance jump instructions.

#5178430 GOTO, why are you adverse to using it

Posted by Promit on 05 September 2014 - 08:02 PM

Do you have any examples of the sorts of circumstances under which more modern compilers are untrustworthy?

It took them years to get the compilers right on the last gen of consoles, at least. Sony spent at least half of the generation simultaneously shipping two independent compilers (common linker) as part of the PS3 dev kit.

#5178370 GOTO, why are you adverse to using it

Posted by Promit on 05 September 2014 - 12:43 PM

Let's not forget that goto fail; happened.

#5178369 GOTO, why are you adverse to using it

Posted by Promit on 05 September 2014 - 12:41 PM

Shifting this into General Prog.

#5178091 One Buffer Vs. Multiple Buffers...

Posted by Promit on 04 September 2014 - 10:27 AM

Is it better to use one interleaved buffer for multiple buffers for vertex/normal/UV data?

Yes to interleaved buffer - the AoS layout is preferable.


Think about what is actually happening internally. You've got a warp of 32 elements being processed. Each one has a vertex input structure, which is going to be a single block of memory containing all of the vertex attributes. What the hardware wants to do is load the entire vertex into the registers of the processing cores. Most likely it's capable of doing this for an entire warp at once. Interleaved attributes allow it to do a single block memory copy to set up all of the vertices to run a warp.


When I was working at NV (2006), it was often the case that non-interleaved streams would be soft interleaved by the driver as part of draw call setup before being rendered. I'm not sure if that's still required on modern hardware or not. But it's best to assume that the underlying hardware is in most cases only able to work with interleaved data. 


Current official advice is to de-interleave only when the update frequencies of the buffer are different.


This advice may further distorted by situations which have lots of data transfer, meaning dynamic/streaming buffers. See L.Spiro's comments here:


Personally I've never seen a reason to worry about this particular bandwidth issue but he probably has more 'in the field' experience than I do on PC platforms and may be able to expand on those comments.