What exactly do you mean by "faking" behaviors?

SM6.0 is tied to DXIL and the new shader compiler (DXC), so the ecosystem isn't nearly as mature as it was for DBC and FXC. But it's been worked on steadily for the past few years, and I've gotten both my home and work codebase running on it. However I've definitely hit some bugs that only on the DXIL path, so it's very possible that you will as well. Fortunately with the new compiler it's very easy to open an issue on GitHub if you need help with something.

As for the wave-level operations in Shader Model 6.0, they're totally optional. The driver has to report that it supports the operations and also for the wave width in D3D12_FEATURE_DATA_D3D12_OPTIONS1, so there's no reason for the driver to say that it supports them if it can't actually do a wave-level operation. Either way Intel, AMD, and Nvidia hardware all work with SIMD units at a low-level, and they certainly support cross-lane operations on those SIMD units.

I have no reason to think that the vendor extensions would work any better than the wave-level intrinsics in SM6.0. Vendor extensions can expose things that are unique to that hardware, but in the case of the wave-level ops the HLSL intrinsics are pretty much identical to the what's in AMD and Nvidia's extensions. Going forward DXIL and SM6.0 are going to be the official path used by games and apps, so there's no reason to think that the IHV's won't put the bulk of their effort into making sure that path is optimal.

Either way the shader "extensions" provided by Nvidia and AMD are a giant PITA to use, since they require binding a dummy UAV and performing operations on it. If you accidentally do that on hardware that doesn't support those "extensions" you could get weird results, and it's also going to mess up the debug validation layer and debugging tools like PIX and RenderDoc. We don't use them in our codebase for these reasons, and I don't plan on starting.

2 hours ago, NikiTo said:

Like the append buffers that suggest some special privileges, but only for DX11.

Everything in D3D/GL is a high level abstraction, that each GPU vendor can map to HW in their own way. AMD has special HW for append buffer counters in D3D11 and D3D12, while NV uses general purpose HW to implement them. NV uses special HW to accelerate the Input Layout / Input Assembler, while AMD uses general purpose HW to implement it. Neither of those features are "fake". 

2 hours ago, NikiTo said:

Baikal maintains high level of performance across all vendors, but it is specifically optimized for AMD® GPUs and APUs."

This could mean two things

- they use a normal set of shaders plus another set based on AMD extensions. 

- they did all their shader optimisation work while using AMD GPUs and AMD's profiling tools. 

2 hours ago, NikiTo said:

While the shader extension sample will run on non-AMD hardware, it will be of limited usefulness, since the purpose of the sample is to demonstrate AMD-specific shader extensions."

This means that the whole point of this demo is to show off an AMD-specific extension. The demo will run, but tell you that the extension is not available (and thus not 'work'). 

Also, forgot to address the actual question in my last post...

SM5 plus vendor extensions is the only way to use these new features in D3D11. 

In D3D12, you have the choice of the ugly/complex vendor extensions (and up to 4 versions of shaders that use them - 1 for each vendor plus one for the case where no extensions are supported!) or using SM6 (and hopefully more like 2 versions of your complex shaders - using wave optimisations and not). 

SM6 is still new. I haven't used it yet because I haven't had time to experiment, but I assume it is the future of D3D shader programming, so anything not shipping today should probably look into it.