To paraphrase my answer to an earlier question, PBKDF2 is a generic high-level algorithm that internally calls a pseudorandom function (PRF) to process its input. The PBKDF2 spec does not mandate any particular PRF, so implementors are free to choose any PRF they want (as long as it meets the definition of a secure PRF, and can accept the input PBKDF2 gives it).
As it happens, by far the most common choice of PRF for PBKDF2 is HMAC, which is another high-level construction that internally uses a cryptographic hash function. Again, the HMAC spec does not mandate any particular hash function,* so implementors are free to choose any hash they want. Probably the most common choice today is one of the SHA-2 family of hashes, which include SHA-256 and SHA-512.
So "SHA512 within PBKDF2" almost certainly means that they're using PBKDF2 with HMAC as the PRF, and with SHA-512 as the hash inside HMAC.**
What may be confusing is that, at a glance, this PBKDF2-with-HMAC-with-SHA512 may look like it's doing something very similar to just plain SHA-512: both take an arbitrary password as input and turn it into a pseudorandom bit string from which the original password cannot be easily reconstructed. However, there are actually several differences, the most important ones being that:
SHA-512 is fast. Very fast. PBKDF2 is deliberately slow to compute, and its slowness can be controlled by adjusting the iteration count parameter.
As a direct consequence of its speed, SHA-512 alone is vulnerable to brute force password guessing attacks using software like hashcat, which simply generate lots of passwords and hash them until they find one that produces a matching hash. A single modern CPU can easily hash millions of passwords per second, and GPUs are even faster.
In addition, there are a few other minor differences with noting:
*) The original HMAC definition and security proofs effectively assume that the hash function used is of a particular type known as a Merkle–Damgård hash function. As it happens, all the most popular cryptographic hash functions for the past several decades, including the SHA-2 family, have been of this type, so this limitation has not been much of an issue in practice. This may be gradually changing with the standardization of SHA-3 (a.k.a. Keccak), which is not a Merkle–Damgård hash, but conveniently, comes with its own security claim for HMAC-SHA3.
**) This is a fine and traditional choice, as far as it goes. It's not as resistant to GPU-based and other parallel attacks as more modern KDFs like scrypt or Argon2 would be, but it's still a lot better than plain old un-iterated hashing. That said, to properly evaluate its security, we would also need to know the iteration count used for PBKDF2. Unfortunately, many PBKDF2 implementations tend to use the old "recommended minimum" of 1000 iterations, which is little more than a speed bump nowadays. Personally, on a modern CPU, I'd prefer something closer to 1,000,000 or 1,000,000,000 iterations.