sure, that everyone have questions and opinions about this idea.
The real question is ( Could this idea be a great benefit to make dolphin emulator better?)
Lol, good answer
That depends on it working the way they described here. If so, it's a good way to speedup emulation for people who have plenty video memory without (I suppose) affecting accuracy. That sounds good to me, what about you guys
(10-09-2010, 11:27 AM)Runo Wrote: [ -> ] (10-07-2010, 05:26 PM)KarstenS Wrote: [ -> ]One point I see, when using FBO for EFB, that it could be possible to use more GPU coding, for example to copy between EFB and texture cache, EFB scaling (for that would be somethin like double buffering needed to get away from the "to texture" hack. One buffer for native data and a second [larger] buffer where the scaled stuff for target resolution gets stored)....
Wouldnt this require multiple codings like, for example one for ATI, one for NVIDIA and etc?
My real question here is: Can this kind of feature be done in a general way, to work for everything without milions of checkboxes?
No, you are over-complicating it, it should be globally compatible. All that would be done is that GPU Vram would be used for EFB copies to Ram instead of system ram.
Considering that not everyone has a decent gpu or a lot of video memory, this should be optional. Only there for those that have enough Vram. Technically it should replace the current Copy EFB -> considering anyone that is able to use Copy EFB -> Ram likely has a decent system, but there will likely be complainers if it isn't made optional and keep the other options if that is even possible.
(10-09-2010, 12:12 PM)knglrk Wrote: [ -> ]sure, that everyone have questions and opinions about this idea.
The real question is ( Could this idea be a great benefit to make dolphin emulator better?)
Yes, if it didn't why would I/we waste time suggesting this? EFB copies to GPU Vram will likely be much faster for anyone that is able to take advantage of the feature. This should net a considerable speedup to games that are heavy on EFB Copies and EFB Copies to Ram.
But how long will it take for someone to compile EFB to RAM
(10-09-2010, 11:27 AM)Runo Wrote: [ -> ]Wouldnt this require multiple codings like, for example one for ATI, one for NVIDIA and etc?
For that there is OpenCL.
(10-09-2010, 01:42 PM)Xtreme2damax Wrote: [ -> ]Considering that not everyone has a decent gpu or a lot of video memory, this should be optional.
Without scaling, the needed vram shoud be equal to the EFB size itself: 2MB
More would be needed, when scaling is used.
FWIW, anything involving FBOs would only work for OGL, since DX only knows textures.
Also, I think many people are misunderstanding this discussion (or maybe it is actually me?) - What X2d was suggesting won't magically speed up the emulator, it gets EFB copying to RAM (which most people don't use anyway for games which don't need it) more up to the speed of EFB copying to texture. Maybe it also speeds up EFB access, but that's all then...
Anyway, I couldn't talk to mudlord, yet, so I still don't know whether HWFBE is a suitable option for Dolphin...
(10-09-2010, 12:12 PM)knglrk Wrote: [ -> ]sure, that everyone have questions and opinions about this idea.
The real question is ( Could this idea be a great benefit to make dolphin emulator better?)
There is a small chance that this approach would combine the speed of "EFB copying to Tex" with the accuracy of "to RAM" and maybe even also allow HD resolutions.
Mudlord did reply again, but it seems he edited he post.
And yes, the idea behind this is to bring EFB copies, specifically Copy EFB -> Ram up to speed with with the Copy EFB -> Texture option. It may also benefit games that are heavy on EFB copies and taxing on the system such as Hyrule Field slowdown. I'm unsure if implementing EFB copies to Vram would solve the latter issue, it's just a guess that somehow it may since the issue with Hyrule Field in ZTP seems to be frequent EFB copies that update the minimap texture every second or less as far as I've observed.
Does anyone know anything about the visor scan problem in metroid prime 2?
Would the scan visor still work with vram or would it be completely broken? jw
(10-04-2010, 05:29 PM)KarstenS Wrote: [ -> ]In that thread the author wrote "but i do not trust the dolphin team to do this safely."
Devs, please give him the answer by getting this to work "safely" 
good job taking it out of context. Btw, i was refferign to direct hardware access, which is impossible under Windows in most cases anyway.
(10-09-2010, 11:29 PM)NeoBrain Wrote: [ -> ]FWIW, anything involving FBOs would only work for OGL, since DX only knows textures.
Direct3D uses RenderTargets as the equivalent.
texture-modification-using-render-targets-with-some-stencil-buffer-action