Degenerate triangles have zero area so they're not rasterized; this is explained some here: http://fgiesen.wordpress.com/2011/07/05/a-trip-through-the-graphics-pipeline-2011-part-5/

This is actually part of both the OpenGL and D3D specifications, where the rasterization rule is that pixels where the center is inside a triangle get shaded - by definition, nothing can be inside a zero area triangle.

Removing such triangles before the vertex shader runs is one of those ideas that seems nice in principle, but when you think about it a little, it actually makes more sense to just let the GPU plough on. You've touched on one of the reasons in your question - how do you know which triangles? Assuming, based on your question, that you're talking about triangles that are non-degenerate before the VS/etc stages run, but become degenerate after (due to transforming, clipping, etc), the only way to know for sure is to run the entire pipeline up to that stage, emulated in software, and in a manner that's invariant with the GPU, for every triangle. So you've just doubled your workload, wiped out the benefits of hardware T&L, and all for a theoretical gain that you may not even get.

Now, about that theoretical gain, one huge disadvantage of this that now arises is that it's no longer possible for you to keep any model data in static vertex buffers. Instead you're going to need to re-send all of your scene geometry to the GPU every frame. Of course you could implement some caching schemes to avoid a resend, but that's more work and will result in uneven performance between the frames where you do send and the frames where you don't.

Slightly more insidious is that the driver and/or hardware may be implementing it's own caching scheme to accomplish a similar result, so you'd also disrupt that. This would, of course, be vendor/hardware/driver dependent.

So the summary is - don't. Your GPU is good at this kind of operation and will be substantially faster if you just let it plough on than if you try to do anything fancy that runs counter to the way it's been designed to work.

Please note that the indices of the corresponding joint vertices might still be different, so the GPU should not be able to discard triangles before the vertex processing stage, meaning that it still has to transform each vertex before finding out which triangle is degenerate.

If you have an unusual situation where this is particularly common, then you might find you're better off using a triangle list instead of a triangle strip. Triangle lists can be optimized to make better use of the post-transform cache and can end up faster than strips even on fairly strip-friendly geometry, so if you have some special case which makes your geometry strip-unfriendly then I would imagine you'll get better performance with a triangle list. I'd echo the other posters though, that in the grand scheme of things it's unlikely to make much difference.

Another point of view is accounting for wasted vertex processing. If every vertex, degenerate or important, gets the same moderate amount of processing (transforming, a few interpolations and texture lookups, etc.) adding x% useless vertices to the real geometry is a x% load increase, which up to a certain point is free.

Anything you do to avoid processing degenerate geometry needs to cost less than x% of clean geometry processing to have a chance of being useful; testing every triangle for degeneracy, even if the cost of rebuilding buffers could be avoided, appears quite out of the question.

The main thing though is that it's a completely pointless exercise. The GPU is already going to do this anyway, so all the proposal involves is repeating calculations that will already be done. There may be a minor saving in bandwidth and vertex processing (although the degenerate verts are quite likely to already be in the cache anyway, so the latter saving is nowhere near as big a deal as one might thing), but at the expense of having to rebuild the vertex/index buffers.

OK, that makes more sense and sounds about right. If it's purely a preprocessing step and everything is arranged accordingly, then yeah, you're going to get better performance under the constraints you mentioned.

Another option you may consider is to make some use of indexing. In that case you retain the cache-optimized vertex buffer but keep two index buffers around, one just omitting indices for the degenerates. There would be some extra memory overhead from having two index buffers, but it could be a worthwhile performance gain.