Normally, you have boards ready, drivers ready and the rest, and you plug the GPU in/solder it down, and run your tests to see if everything comes up OK/correctly. This shouldn't take long. If you have bugs, the test itself should narrow down where it is in silicon. If not, you didn't prep right. Finding, fixing and verifying the fix should be fairly quick since it is likely a pretty specific change.
Maybe GPU's live in an entirely different place, but whatever it is that you're describing is a complete fiction in my world.
The problems you tends to hit during silicon validation are not the ones that are easy to narrow down with a targeted test. Those are usually found and fixed during module simulations. You will typically rerun your chip-level verification suite on the real silicon, but that's the easy part: they are supposed to pass because they did so in RTL or on some kind of emulation device. The only reason you rerun them is to make sure that basic functionality is sane.
The things you run into on the bench are hard to find corner cases. Something that hangs every 10 minutes. Or a bit corruption that happens every so often. They are triggered when you run the real applications, system tests that are impossible to run, even on emulation, because it just takes too long. In telecom, this may be a prolonged data transfers that suddenly errors out or a connection that lose sync. In an SOC, some buffers that should not overflow suddenly do or a crossbar that locks up. A video decoder may hang after playing a DVD for 30 minutes. When these things trigger, a complicated dance starts to try to isolate the bugs. It can take days to do so. Very often there is a software fix by setting configuration bits that, e.g., may lower performance just a little and disable a local optimization, but sometimes there is not. These kind of problems are present in every chip, but even if they're not, you need wall clock time to make sure they are not. Did I mention that sometimes you need to work around one such bug first before you can run other system tests?
And then there's the validation of analog interfaces: making sure that your interface complies with all specifications under all PVT corners takes weeks even if everything goes right. (Corner lots usually arrive a week after the first hot lot, so your imaginary 2 week window has already gone down by half.) You need to verify the slew rates and driving strengths of drivers. Input levels of all comparators. Short term and long term jitter of all PLL's. etc.
The whole idea that you can do all that quickly and then do a respin in 2 weeks is laughable (and you'd be an idiot to do so anyway: you know there are stones unturned if you do it too quickly.) If everything goes well, 5 weeks is the bare minimum.
And what about the claim that you can fix logic bugs with just 2 metal layers (the real smoking gun if ever there was one that you really don't know what you're talking about, thank you). This would mean that you're only changing the two upper metal layers out of 7 or 8. Which is surprising because, as I'm sure you're aware, the wire density of M7 and M8 is low. There doesn't happen a lot of interesting stuff at that level, so the chance of fixing anything remotely useful is very, very low.
You usually get away with not having to touch M1, but in 99% of the cases, you don't even bother looking for a fix that doesn't touch M2. Respin time is 100% a function of the lowest layer you change. If you change M2, it doesn't matter that you also modify M3-M8. The majority of backup wafers are parked before M2 or V1.
You may or may not have great insider info about tape-out dates and other dirty laundry. It's very entertaining, but please stay out of the kitchen?
