The whole point of Password-Authenticated Key Exchange mechanism is to enable establishment of a shared secret when the two parties do not have better mutual authentication mechanism than a shared low-entropy secret (the password).
If the client can know, with decent certainty, the server's public key, then the client can simply use that knowledge to open a secure tunnel with the server and send the password in that tunnel. This is what happens all the time when some human user with a Web browser connects to a HTTPS server, and types his password: the client authenticates the server thanks to its certificate, and that's enough to power up a SSL, at which point the password can be sent "as is" since the client has some guarantee that it is talking to the expected server.
Thus, if you begin by assuming that the client knows the server's public key, then there is no need to use SRP at all. Moreover, if you assume that the server also knows the client's public key, then you no longer have to use a password at all.
Consider password registration: prior to that operation, there is no "shared secret" between client and server. Yet, the client will thereafter use that knowledge of the shared secret to authenticate the server. This means that there must be some other authentication method to be used at registration time, by which the client can make sure that it is setting things up with the genuine server.
You may envision the case of a client who registers through a SSL-powered Web interface (server certificate is used by the client, to make sure that it talks to the genuine server); then the registered password will be used thereafter, e.g. from a client device where certificate validation cannot be done conveniently.