There are two general cases for using a physics system in a game:
For gameplay. That is, using forces and collisions to move objects around. The physics system manages the location and movement of game objects.
For visualization, things like particle systems. These are pure-rendering things that don't affect gameplay.
Handling #1 on the GPU is a bad idea performance-wise. The problem is that you need to do a CPU->GPU->CPU round-trip. The CPU needs to manage where objects are, so that AI and other systems can manipulate it. Therefore, the CPU may need to update the position of objects. The CPU also needs to read the positions of objects, as well as be notified of any collisions. So you can't just fire off some GPU "rendering" commands and then do something else; you need that information right now for AI and the like.
This forces a GPU/CPU synchronization. A GPU/CPU sync is one of the worst things you can do for performance. You want the GPU to operate as asynchronously as possible. Doing physics of type #1 on the GPU works against that.
Now, for #2 physics, things are different. In this case, the physics is completely subservient to the rendering of the object. It basically does physics solely to do rendering. Therefore, everything can effectively live on the GPU. For this, doing the physics on the GPU makes sense, because the AI and game engine don't care about any collisions or whathaveyou.
I don't know of anything complex enough for people to call it a "physics engine" that doesn't handle at least convex hulls. You can generally build concave meshes by taking many convex hulls and using constraints to effectively fuse them together, though how well this works depends on the physics system.
Many physics engines do have some way to run on GPUs. PhysX and Bullet have some mechanisms for it, though it may be limited to certain hardware that provides appropriate support.