Register a free account today to become a member!
Once signed in, you'll be able to participate on this site by adding your own topics and posts, as well as connect with other members through your own private inbox!
An apprentice?! I hope he's up to standard mate!
FLOL!
Piece of cake, mate. I've even changed headlight bulbs, oil and filter AND successfully bled my brakes. Just. It was a struggle.An apprentice?! I hope he's up to standard mate!
Congratulations on the work and effort over the past year; I can imagine how much work has gone into that. I'm sure that my current client could do with someone with your skills at the moment! Are you effectively at a stage now where you have a 'product' based on your work?
FLOL!
Fair play - it makes sense bringing it all in-house given the uncertain future and specialist domain in which you're working. I'm sure the investment will be repaid in no time, if not already. And several times over. I won't lie though... I'm not sure I would have the patience and will/desire to write a Java VM...
Hahahaha!
No, not bad going at all mate! It's funny how things work out sometimes. I don't know much about radar at all - it goes way, WAY over my head and level of understanding. It sounds interesting when I hear folks talking about it in work but it's definitely - as you say - voodoo and black magic!
This time I've added motion blur, which is determined by the object's velocity, time sample (period over which the motion is sampled) and the camera shutter speed. It only works on sphere primitives at the moment. 
In the likes of the above the only thing the Quadro GP100 would leave you with is a much emptier wallet...! To be fair, the Big Pascal Quadro GP100 is a bit of a strange card from nVidia and, I think, has a quite specific market. It's got great performance for graphics and FP32 compute, but not as good as the lesser Quadro P6000 (I say lesser yet the P6000 still costs over 6 grand). It's the FP32 performance that is key here and considering the fact that Titan Xp and 1080 Ti perform better than the Quadro P6000 we can quickly see that:
Yeah, I'm not surprised they fly on that machine.
@Darren S - Good question
Titan Xp / 1080 Ti > Quadro P6000 > Quadro GP100
Of course, things are never quite as clear cut as that and the comparison I give here is very much based on the fact that we are only talking CUDA / OpenCL path tracing and ray tracing type applications that use single-precision (FP32).
The majority of rendering tasks on GPU don't require FP64 double-precision. In fact, you can quite easily produce movie quality CGI using FP32 as it affords plenty enough precision to generate realistic visuals (time and resources permitting). As a result, you can happily use a mainstream Geforce GTX with CUDA support for handling the grunt work and, in pretty much most cases, you will find that the Quadro is out-performed by the gaming Geforce GTX (or Titan) GPU. The number of CUDA cores and the clock speeds are key here. The more CUDA cores you have, and the faster they can run, the better. If we take a look at the GP100 and the 1080 Ti they appear similar in terms of CUDA core counts and clock speeds (more or less) but the 1080 Ti has the edge with higher core clock and boost clock rates. Simply put, the 1080 Ti has the faster and better FP32 compute performance as a result. I have seen the likes of the 1080 Ti (and Titan Xp) outperform the Quadro GP100 by some 30% in progressive refinement rendering tasks (such as Monte Carlo path tracing). Of course, the GP100 does have the higher bandwidth HBM2 memory interface and greater capacity for throwing data around... but this doesn't really have much of an impact with these sorts of rendering tasks (which are low latency). You don't need that bandwidth with this GPU compute tasking. Hence, to answer your question, the GP100 would offer no benefits for the above and would result in a lower-performance path tracer.
However... the Quadro GP100 does have additional benefits if you need the GPU for other tasks, such as CAD. It will run circles around the gaming cards for pushing polygons in a CAD environment where wireframe views, 2-sided lighting, etc. are king. It also has ECC memory, is more robust and is designed to run for prolonged periods whilst drawing less power. There are many other benefits too but, alas, nothing that really would make you choose it over a much cheaper 1080 Ti for rendering using GPU compute.
That said, the higher onboard RAM capacity can be useful with the Quadro cards. When rendering with GPU compute you really need to have your ENTIRE scene in memory at once to get maximum performance benefit. As soon as you exhaust GPU memory you're often in a whole world of pain. Some systems will drop back to a CPU-based render path (ouch, MUCH slower) or employ some clever page-swapping, which also massively hurts GPU compute performance - although likely not to the extent that a pure CPU-based render path would incur. Hence, a heap of onboard RAM is always a bonus.
Yeah, the GP100 range have NVLINK which considerably ups the bandwidth between two GPUs. The 32GB memory is definitely a bonus, too. However, having not explored that particular avenue in depth as yet, I'm not sure whether or not each GPU still has to maintain its own copy of the data for rendering the scene or whether a not a single copy of the data in the 'shared' memory is now sufficient. In my setup, I am limited to the amount of RAM on a single GPU. Whilst my path tracer would scale quite nicely on multi-GPU setups I still have to provide a copy of the 3D scene data to each GPU wholly. This may no longer be necessary on the Quadro GP100... not sure buddy!
Me too, mate. Constantly. It's the sweat due to the heat these things kick out!!!!
That’s why god invented GIT!
A few more random images... Again, this is all rendered with zero direct lighting and is all wholly lit by the indirect light from the surrounding environment. This is sometimes referred to as global illumination (or indirect illumination).
Whoa! That sounds like an interesting 'mix-up' somewhere in the depths of GIT... have you got it sorted now mate?
I've just got to figure out the best way of getting the texture data to the GPU and associating textures with materials. Here are a few test renders with simple 3D models and basic diffuse / albedo texture maps applied, rendered using a HDRi environment map for the global illumination in an attempt to 'sit' the models into the scene.
My point is that some materials are considerably more complex to simulate and the more pixel area those materials cover, the more the performance is impacted. In terms of ray/path calculations we are talking in the billions and trillions of calculations per frame. The numbers genuinely are astronomical.
As per usual - thanks Andy for twisting my tiny brain!@Darren S - I think I understand what you are saying...
First of all, let's get the physics out of the way! As you are no doubt aware it it possible to run physics simulations on the GPU these days. However, this is not the case here (the GPU is purely being used to trace the rays/paths of light bouncing through the scene and ultimately generating the resulting image). My little physics simulation is running on the CPU. I take the results of the physics simulation and 'mirror' them to their corresponding GPU counterparts (effectively updating their positions, velocities, etc). The results of the CPU simulation have to be uploaded to the GPU each frame (the physics simulation is running at 60 fps independent of the rendering frame rate). Due to the fact that the physics simulation is quite simple - and running on a rather tasty CPU - the performance hit is pretty much negligible. Consequently, the dynamic nature of the balls don't impact much at all on performance. It's the rendering of the balls that really impact the performance in a significant way.
If we consider the balls in the first part of the demo there are several different materials applied to them. It's in the realisation of these materials where MASSIVE performance gains or losses can be found, due to the complexity of the mathematics behind them. Likewise, the complexity of the materials and how much of the view is covered by those complex materials also makes a big difference. If you are rendering a single ball that is some distance from the camera then it might only cover an area of, say, 10x10 pixels (100 pixels) in total. However, if that same ball is right in front of the camera and occupying the entire view then you suddenly have to consider, say, an area of 1920x1080 pixels (2,073,600 pixels) for a HD display. As path tracing is performed 'per pixel' then you suddenly have MANY more computations to crunch through.
The following materials types were used in the demo - diffuse, metal, emissive, 'coat', ideal specular, ideal refraction - and they all have varying levels of computational complexity and cost. The ideal specular material (i.e. the mirror chrome-like material) is quite 'cheap' to render compared to the ideal refraction material (i.e. the glass-like material) for example. I'm not sure you'd be too interested in the reasons why so I won't go into detail here as it might get a bit boring!
Another factor impacting the performance is the number of 'bounces' a path can take through the scene. The more bounces a path takes, the more realistic the result (at the expense of computational cost). Consider a ray is traced from the camera and into the scene. If it hits nothing in the scene then the camera simply takes the colour of the environment and moves on to calculate another ray. However, it might hit an object. That's a bounce. At that hit point we need to query the material properties to determine how the ray's path is affected. Is it reflected, is it transmitted (e.g. through glass) or something else? Let's assume it's a mirror material so the ray's path is reflected based on the angle of incidence. That newly created ray then continues the journey through the scene. It might not hit anything else at which point it escapes into the environment and we start again with another ray. But, that new path might hit another object. That's the second bounce. We go through the same process of querying the surface, determining how it affects the ray, and so on and so on. The more bounces that happen, the more accurate the generated colour for the pixel being rendered. The bounce count can be imposed by a hard limit or sometimes analytically (I use a hard limit). I generally impose a limit of 4-8 bounces for 'pretty' renders. Pixar used 10 bounces for Big Hero 6 as it required that many bounces to provide a suitably realistic appearance for the white inflatable suit.
With respect to your question on people walking up and down the alleyway and the impact on performance... yes, it would adversely affect performance. It's not really possible to say by how much, though. It (again) very much depends on the complexity of the materials used to realise those people. Geometric model complexity would also add cost (i.e. more polygons mean more intersection / hit tests have to be performed by the GPU to determine if rays hit the geometry or not). Due to the recursive(ish) way that path tracing works the reflections would happen automatically so the balls wouldn't need any additional information to tell them to reflect the people walking in the alleyway.
Real time path tracing (as I'm doing here) really is sensitive to material and geometric complexity. It's so very easy to completely use every bit of performance the GPU has to offer (and then some) resulting in horrendous performance dips. I've caused the GPU to slow to such a degree that the Windows watchkeeper process thought the driver had crashed and thus performed a GPU/driver reset (completely crashing the renderer!)
TL;DR - it depends.
?Experience is everything mate! It probably sounds / reads a lot more complex than it is. Maybe. Hmm.
If the entire background was black then the resulting image would be black... unless at least one of those balls was a light emitter or there was some form of direct lighting being used to illuminate the balls.
The background light is used to light the scene in a physically accurate way hence why the alleyway background in my demo is encoded as a HDR image - providing both colour and light intensity information. It also does not matter what colour the background environment colour actually is. The exact same process and calculations have to be performed to trace a ray's path through the scene. The only difference is that, with a black background, when that ray ends its processing it finds a black environment hence there is no light information available. The pixel renders black (assuming, as already said before) there's no other form of direct lighting from elsewhere. Seriously, it really does. If we assume that the balls all use exactly the same material then we still cannot say for sure. With path tracing there is an element of randomness in terms of calculating the direction of rays travelling and bouncing around a scene. It's quite possible that the balls may be in such positions that rays hit and bounce off many other balls before finally resolving to a pixel colour contribution. There really isn't much in way of a clear answer. That said, if we dumbed down the rendering to a minimum such that complexity was pretty much the same for the two scenarios then, yes (as a rule of thumb) a 2x increase in pixel coverage would typically equate to a 2x increase in computational cost. Texturing itself isn't too expensive and still offers a way to increase perceived image fidelity whilst keeping geometric complexity down. For example, through the use of bump and normal maps to simulate surface perturbations rather than actually having those perturbations modelled using millions of additional polygons in the 3D meshes (as seen in all modern day games). If the textured surface is a simple material that returns the texture colour then that's a fairly minimal cost. If it uses a normal or bump map to alter the direction of the ray that hit the surface then the cost goes up a bit as the new direction the ray must take is affected by the data in the normal or bump map. Again, on its own, it's not a particularly expensive step. However... if it's a texture representative of human skin on the face and the material is simulating skin then the cost can increase significantly. Skin is expensive to simulate. Some of the light hitting the skin is reflected, some is absorbed. Some of the light enters through the skin, bounces around just under the surface of the skin, and then exits at some point later (subsurface scattering).
