Software Rendering and OpenGL Textures

I have been told that the bus between main and video memory is too slow to allow for constant updates to large textures. This seems like it would rule out, say, rendering a screen of a game in software then dumping it to the video card via OpenGL for postprocessing.

However, it is my reasoning that an emulator developer should want to do exactly this. An array of pixels would be easiest for an emulator to work on. Most emulators offer a DirectX or OpenGL mode for better sync, which makes me wonder what's going on underneath.

I'll get to it, then: Would it be feasible for a 320x240 game to be rendered in software, with the screen updates pushed to video  memory on VBLANK for postprocessing (upscale, scanlines, etc)?

Jesus Fucking Christ. Why do "software engineers" suck so much at even estimating even orders of magnitude? No wonder this "science" is such a joke.

Have you ever heard of "mplayer"? It's a video player. It has several output modules, some being OpenGL based (-vo gl). Now, according to your armchair calculations, playing a video like that would never have a chance to work, right? Not even for a 320x240 video¹.

>>6 is right that readback is generally slower. That doesn't stop people from capturing 1280x720 videos at 60 frames per second (while running the fucking game in the first place). What does that tell you?

I mean, it takes literally less than five minutes to look around you and see what is feasible and what is not, because it has been done before to death.

¹ Pedants will point out that video is generally uploaded in YV12 colorspace, which takes less bandwidth than RGB32. You are cordially invited to use a 1920x1080 video and force a software conversion to RGB32 for this test.