Since Dave said emulators can be discussed as well...

[K.I.L.E.R]

I thought it was only a console forum until Dave said it in the Feedback forum.

Anyway, I will start with something that has been bothering me about Pete's [EPXSE] OpenGL 2.0 plugin and the use of shaders.

GL2.0 plugin is currently based on GL 1.4 with IHV extensions because GL2.0 isn't out yet.
Before Pete released the GL2.0 plugin he had the original plugin based on GL 1.xx with no IHV specific extensions unless a specific fix was required.

Before GL 2.0 plugin was released Pete complained about Ati's framebuffer access speed. It was originally slower than the NV25's, because of that it had caused problems such as very slow framebuffer effects. Framebuffer textures worked perfect though.

Anyhow I had asked Pete in the past if he could use shaders to speed up the framebuffer access in some way but his response at the time was one that I didn't like. He said in general that it couldn't be done.

Well now something has been done as I get no speed issues with framebuffer access. Guess how he managed to do it?
Using shaders.

Does anyone here know enough to make a comment on how he managed to do it?
Did he trick the emulator into thinking the VRAM is the system memory and that's where everything got stored?

I'm quite amazed that Pete managed to pull something off that he thought was impossible.
Guess my original thoughts were right? I always thought shaders could do it but I never knew how.

 

[Grall]

Generally framebuffer access IS quite slow due to all the "traffic light intersections" data have to pass through.

First your writes have to make it out of the CPU itself, competing with whatever other bus traffic's going on. The data then ends up in the chipset's AGP write buffers, then it passes across the (highly latent) AGP interface and ends up in the chipset's write buffers waiting to get written to memory. Not sure if the memory controller differentiates between CPU framebuffer write requests and writes it itself have to do, or if that is even possible (maybe separate buffers for AGP and internal writes?), and if so how it prioritizes between the two. Net result is that manymanymany CPU clocks pass before the operation is actually completed...

Naturally, reads are even worse since first the read request has to make it out of the CPU and across AGP to the GPU, which then deliver the data in the reverse direction, probably at its leisure. Depending on wether fast writes are enabled/used, data traffic might even first pass through main RAM, adding additional latency each way.

Framebuffer reads were said to be in the MB/s speed range I heard back around the time of the original R300 launch due to there not being much point in it being fast (since no software really reads back the framebuffer anyway).

It was implied reads could be vastly improved in speed, but there was little incentive to improve the drivers in that direction since it was a pretty much useless feature. Beyond the screenshot save function in games, which programs needs to read out the framebuffer anyway? Well, this was almost a year ago I think when people were excited about doing high-speed 3D rendering to harddrive to replace 3DStudio Max and such programs, though to compete with such programs from an image quality point of view, rendering speed would be so slow anyway that AGP read speed would be the least problem probably.


*G*

 

[K.I.L.E.R]

Grall, I know all that but the questoin still remains, how are shaders responsible for speeding up the framebuffer access?

 

[Tagrineth]

Grall, I know all that but the questoin still remains, how are shaders responsible for speeding up the framebuffer access?

Easy.

One VERY simple method is take the framebuffer effect and come up with a pixel shader that completes an equivalent effect. =)

 

[K.I.L.E.R]

Grall, I know all that but the questoin still remains, how are shaders responsible for speeding up the framebuffer access?

Easy.

One VERY simple method is take the framebuffer effect and come up with a pixel shader that completes an equivalent effect. =)

Thanks.
I never knew it would be that simple.
I wander why Pete couldn't figure it out at the time? Maybe he didn't have experience with shaders to make a real judgment?