The PBR book I linked above basically starts out by saying that PBR is ray tracing1.
No, they don't. pbrt is the name of the framework they walk you through in the book. You can find the accompanying source code here: https://github.com/mmp/pbrt-v3
The book walks you through the implementation of a ray tracing framework which uses physically based shading models. This doesn't mean that physically based shading is exclusive to ray tracing.
As mentioned before, physically based rendering is just an approach to shading and lighting with a foundation in the actual physics behind lighting and reflections, rather than working backwards from "what looks right" like we used to do in previous generations.
Seeing as misaligning the root signature on purpose causes an error telling me I'm binding the wrong descriptor table type (for example), it seems like the implicit root signature in the compiled shader is known. How do I get it via reflection?
As far as I'm aware you won't be able to retrieve a root signature from your bytecode if you don't explicitly define it in your shader code.
One type of validation you could do is to get information of SRV/CBV/UAV/Sampler bindings using shader reflection. You can cross-reference this data against your root signature to see whether the root signature has the appropriate descriptors, descriptor tables, constants or static samplers to support your shader.
Other than doing that I don't think you can actually extract explicit root signature information out of a shader without defining it in your HLSL code.
I'm looking at the ability to render as many entities as possible to the screen before it drops the frame rate below 60 FPS.
Honestly, you're going to run into a ton of actual rendering-related bottlenecks before a decently architected game object/entity/"whatever buzzword you want to use" system gets in your way. Don't start theoretically optimizing things. Solve the problems you have at hand to get to the desired frame time for your specific game.
Spread that 16ms out to every system??? Are you trying to run every system at 60FPS? That's wasteful and pointless....
You've obviously never worked on any type of shooter before. Try telling that to people designing any type of competitive game which supports split-second inputs. 16ms in a game update tick can definitely make a difference.
Not to mention there's the option to run your rendering on a seperate thread asynchronously, which most games don't even do anymore.
What are you talking about? There's a ton of games doing async rendering? The era of single-threaded update and render is over!
Still looking for more improvements that will make this even more efficient. But my question is actually really simple, how fast are your engines running and what specific design patterns are you using to improve how many simultaneous entities can exist and be drawn without slowing your engine down. I'm trying to find a goal to shoot for and new ideas to improve my own engine.
This is still a very useless comparison to make. You're acting like every engine is comparable in some shape or form when it comes to performance. They're not. Focus on what your requirements and goals are. Do some profiling, find your bottlenecks, fix them. Rinse and repeat.