I was under the impression that it was re-programmable? I could be wrong, but if it only does pro-res at the moment I thought that was purely a software issue - isn't it essentially just a big FPGA that can be re-purposed?
Huge difference between reprogrammable by Apple and reprogrammable by random "Joe" developer. The Afterburner is not presented to the end users to use. Programmers make a Apple standard A/V API call. Inside Apple's library if the Afterburner is present that 'work' is handed to the card. If it isn't present the same call is handled by software. The card itself is opaque to the applications.
The reprogrammability is that
Apple could add some other path for some other existing API call to redirect the work to the card. For example, can now decode up to 4 8K RAW streams. So what if reconfigured the transistor connections so that there was a 1-2 stream decoder and 1-2 stream encoder on the card. Reconfigure and perhaps Apple's compressor sends a simple (no add on render overlay) job to the Afterburner card to transcode to another format. Goes into the card in one format and comes out in another Apple/Open format.
Similarly if had two Afterburner cards installed. One does decode and the other does encode could do some quick transcodes that way.
There are a number of things Apple could do with just the existing or slightly expended A/V API that could be shuffled to the different "fixed function" engines on the Afterburner card.
One of the primary issues is that Apple's libraries is going to probably rely on knowing what the computational engine state of the Afterburner call is. To have the fastest, cleanest path through the standard library call not going to want to do:
1. query what the FPGA state is. Is it Afterburner that matches this library call. No? Is there some other process on macOS using the card? Yes. ... do what? wait or use the software version. Nobody using now? Are they completely done or paused or timesliced out in a in between state? Request exclusive access to the FPGA card ? Still too long. Punt to software version? etc.
versus radically more simple code.
2. Is the card present? Yes .. use it. Otherwise don't use it.
Once make it a dynamically configured shared resource, you then open up a whole can of worms. This is way easier to deploy in a highly bug free roll out. Focused mission and fewer bugs probably makes it worth more to target audience aimed at.
Over time ProRes rolled out new formats. The first non RAW ProRes format wasn't the last. Over ProRes 4444 came later than the initial basic one. This ProRes RAW probably will get updates. Chroma log changes or new ideas. Substantive different data loads ( crazy 16K sensor with its scaling issues. ) etc. 3-4 years from now minimally there will probably be another ProRes RAW addition to the list of formats. That is why it is a FPGA. If it was an ASIC would have to tell folks to buy a whole another card.
It costs more to fab a ASIC in very low volume numbers. The low number count is why use a FPGA ( more folks with different needs can buy the same thing and lower costs by collective volume buying. ) . Some folks buy FPGA to debug their ASIC designs before do fab them. Just because it is a FPGA doesn't mean that single user has to put it so divergent uses.
I suspect there will be an "Afterburner 2" if the units sold numbers turn out decent over 2-3 years. PCI-e v4 interface and more programmable transistors connection will allow a future card to do more in a fixed space in a future system with more bandwidth. The current Afterburner card will probably still be useful though.
And for the Mac Pro system in general, if there was some huge deep seated need for direct programmer access to a substantive FPGA then some 3rd party could sell a FPGA card ( same as done with Linux / Windows boxes. ). macOS doesn't particularly prohibit it, it just require some driver work be done.
