>> There's hw we care about which can't do this (i965, svga) and >> it seems unreasonable to expect them to do workarounds just so this >> extension can be always exposed. >> >> >> With all respect, when I ask for a cap bit for an unsupported feature in >> the driver I work on, I am always told to implement a bloody-slow >> workaround with a lot of code around, but when comes to the drivers you >> guys care about, it's just "let's add a cap". Can we be fair here? > > Well it's a somewhat advanced feature because it's only required by GL > 3.3, and the functionality is not present in DX10. > Personally I'm not really against requiring drivers to implement this > (though I'd like to hear more opinions), however whoever introduces this > feature should then also try to unbreak the drivers.
Well the upstream 965 driver already implements this so I expect our i965g port should also do it if worked. Everytime you guys introduce a feature that you consider necessary for svga, someone from r300g (MAD or Marek) fixes up r300 pretty quickly afterwards, again I'm seeing a bit of a double standard here. I'm not against a CAP bit but I'm quite willing to fix softpipe + r300g to pass the glean test and other driver writers can notice in their regular piglit runs the test fails for them and they can fix as and when. Dave. _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
