If you mean "different code paths for 9.1 Cat and 9.2 Cat" then I agree completely; code for the most recent. In a case such as pre-6xx support stopping at 9.3 you might end up with a bit of code specific to 9.3 on pre-6xx but in general you want to code for the most recent driver on any hardware class.
This all echoes around between the vendors of course; it's not unusual for HW vendor A to have a bug, app vendor B to code in a workaround for that bug which breaks support on HW vendor C, so HW vendor C's drivers have to be hacked to duplicate the buggy behavior under certain conditions to make the app work, then when HW vendor A fixes their bug the new version of the app takes out the workaround and HW vendor C has to change *their* driver to take out the simulated bug which made the previous version of the app work. When anyone fixes a bug it takes a while for the ripples to fade
Between the proprietary and open source drivers I would expect some differences, but the code paths will probably be different anyways because of the different extension sets and the branch criteria would probably not be based on the driver itself.
This all echoes around between the vendors of course; it's not unusual for HW vendor A to have a bug, app vendor B to code in a workaround for that bug which breaks support on HW vendor C, so HW vendor C's drivers have to be hacked to duplicate the buggy behavior under certain conditions to make the app work, then when HW vendor A fixes their bug the new version of the app takes out the workaround and HW vendor C has to change *their* driver to take out the simulated bug which made the previous version of the app work. When anyone fixes a bug it takes a while for the ripples to fade
Between the proprietary and open source drivers I would expect some differences, but the code paths will probably be different anyways because of the different extension sets and the branch criteria would probably not be based on the driver itself.
Comment