It's hard to tell exactly what you're asking, but I believe the answer is:
It's not strictly necessary, but it's almost always a good idea.I'm going to assume what you're referring to is the fixed timestep technique, in which rendering is done once per frame but game state updates are only done at fixed time intervals. This means constructing your main game loop like this:
sf::RenderWindow window(sf::VideoMode(800, 600), "timestep");
sf::Clock clock;
const double timestep = 0.002;
double unprocessedTime = 0.0;
while ( window.isOpen ) {
unprocessedTime += clock.reset().asSeconds();
while ( unprocessedTime >= timestep ) {
unprocessedTime -= timestep;
update(timestep); // physics, AI, etc goes in here
}
window.clear();
window.draw(/* everything */);
window.display();
}
The idea is you render your game once every frame no matter what, but you only update the game's internal state (eg, the current position of all players, enemies and projectiles) once every 20 milliseconds (or some other fixed value).
The essential part is that your game state updates must take time into account. Otherwise, the game plays faster on faster machines, and slower on slower machines, which typically means it's completely unplayable on most machines that aren't yours. This can be easily achieved simply by keeping track of deltaTime.
Upgrading this to a fixed timestep is technically optional, but practically speaking you usually need to at some point. The problem is that doing one physics update for 1 second is often different from doing a thousand physics updates for 1 millisecond each. If projectiles pass through you in less than a second, this makes your game's physics very inconsistent. It also becomes far easier to implement advanced features like online multiplayer, efficient replay storage, and time-rewinding mechanics if you design everything around a fixed timestep.
Now to answer your question directly. You specifically asked about separating "input updates" (which I assume means updating the game's state, partially based on user input) from "rendering". Technically, you can use deltaTime or a fixed timestep on rendering as well, and it would probably be okay.
The reason we don't do that is because we have good reasons for restricting how the game state is updated (which I explained above),
but those reasons do not apply to rendering. Even if the game state should only be updated once every 20 ms, the game will still look or feel smoother if we render frames more often, especially if we introduce some prediction logic and/or cosmetic animations into the rendering system. On the flip side, if we hit a lag spike and suddenly need to do multiple physics updates in a single frame, it obviously makes no sense to render the game multiple times during that one frame.
Obligatory link to the classic article on this subject:
http://gafferongames.com/game-physics/fix-your-timestep/