Quote:The way a console works is that it has really good hardware (i.e. graphics card, CPU, ect...) but very little RAM. So in order to run games, they are produced to run games almost solely in VRAM, which poses a problem when you try to create an emulator, where PCs have alot of RAM, but not-so-good graphic cards.
I disagree with every single part of that. First of all consoles don't have good hardware compared to a pc, especially the wii. Second games on consoles do not "run almost solely in vdram" they usually use up all of the main memory and stream data into the memory off the HDD/optical drive as the game is running, and they use the vdram the same way pc games do. And that last part doesn't make any sense. PCs don't have good graphics cards? Any half decent pc video card has several times the vdram bandwidth of the xbox360/PS3 and dozens of times the vdram bandwidth of a wii. The problem is simply that while the individual components of a pc are amazingly powerful compared to a console they have very little bandwidth with each other. In a console although the individual parts are inferior the bandwidth between components like cpu/gpu/memoryis much higher than in a pc. This is why cosntant framebuffer read/writes slow down emulators so much. On top of that the wii has 2MB of edram specifically for the framebuffer, which is specifically designed for constant read/write. The entire content of the edram can be flushed with a single clock cycle if I am not mistaken. This issue has nothing to do with consoles having better hardware or running games "almost solely from vdram". If you have any cross platform pc games installed take a look at some of the .cfg and .ini files in notepad and you will see what I'm talking about, they usually have a section in their for the consoles since they are to lazy to remove it which maps out how the memory is allocated to the game for various things.
Quote: And the amount of time and coding it'd take to do that would be like redesigning Dolphin from the ground up.
Not really. The efb emulation is just one of of many parts of dolphin (the amount of code isn't even that big compared to most other things). The amount of code needed to do this would be insignificant, the problem is just that the devs don't know how to do it.
Quote:There are just so many graphic cards on the market, that even new PC games often have compatibility issues that take patches and hotfixes to figure out.
Not really a problem. All video cards handle most of this stuff the same way (except intel igps of course). Todays video cards do the same things the same way using the same apis. If working vdram based efb emulation was introduced it would work on all video cards since the drivers are responsible for how the hardware handles it, not the application (I mis-phrased that but you know what I meant to say).
Quote:maybe efb to ram is the wii ram, which is emulated. efb to texture goes straight to the models I presume.
Well that is just speculation. We need someone to get in here who actually understands how dolphin handles the efb and have them explain it to us.
Bumping up for visibility.
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"
It seems you are a bit too optimistic about the developers capabilities. Sure there are some talented developers that have committed some groundbreaking code that resulted in groundbreaking improvements, but there are also several amateur developers that have mangled the code, creating more issues, causing old issues to resurface, regressions that shouldn't have happened with a team of highly skilled developers. Some of them are also slow to fix issues that their commits create, adding new (useless?) features and giving little attention to fixing existing issues. Dolphin needs a project manager to oversee development, commits need to be tested by developers before committing to the repository.
The expressed concern about doing this safely is valid, direct hardware access can open a whole other can of worms if it is done improperly. It can be done though and framebuffer effects such as efb copies should be much faster by copying to Vram instead of system ram.
I would like to hear a more from developers, it doesn't seem like many developers have acknowledged the suggestion so I would like to see what they think and if there is any consideration to implement this.
(10-05-2010, 09:49 AM)Xtreme2damax Wrote: [ -> ]as efb copies should be much faster by copying to Vram instead of system ram.
Copy to texture = Copy to Vram, or am I missing anything?
Neobrain, you should read the replies at Xtemu..
Squall Leonhart Wrote:NaturalViolence Wrote:Squall Leonhart Wrote:Squall Leonhart Wrote:it is a primative method of applying a frame buffer effect, such as bloom, blur, shading, etc to a clear texture and storing it in vram, the downside is that it doesn't allow for CPU updates of the texture as only the GPU can modify textures in storage (Virtualised Textures storage). If you had direct hardware access then you could modify directly, but i do not trust the dolphin team to do this safely.
Framebuffer objects, on the other hand can be directly modified by either gpu or cpu whether they are copied back to Sys ram or not.
http://www.mathemati...u/tutorial.html
http://74.54.224.213...fer_multisample
http://en.wikipedia....mebuffer_Object
[url=http://www.gamedev.net/community/forums/topic.asp?topic_id=537097"http://www.gamedev.n...topic_id=537097[/url]
copy efb to texture prevents msaa as it creates fake textures, and MSAA cannot be applied to a texture mirrored in sys ram
lol... they use peek z.... slow ass....
to a clear texture and storing it in vram.
So it does store it in the vdram just not as a framebuffer object?
as a static object.
This:
Squall Leonhart Wrote:the cpu cannot directly interact with EFB textures.
the cpu can directly read/write EFB FBO objects.
This:
Squall Leonhart Wrote:EFB to texture and EFB to FBO are both vram storage.
FBO's can be modified, while Textures cannot.
And this:
mudlord Wrote:No, there is some ways to accelerate CPU writes. You can pack the content into a offscreen buffer, copy and unpack. And vica versa.
The code is more complicated but it can be done. Squall: Framebuffer objects have texture attachments, for colour buffers and depth buffers.
Just so you know Squall Leonhart has been around the emuscene for a while like myself, not as long as I have, but he is quite knowledgeable. Mudlord has also been around for a while, is very knowledgeable, started the VBA-M emulator, created his own NES emulator and contributed improvements to Bsnes. Squall Leonhart also runs the VBA-M forum and oversees development, what they've said is pretty much valid.
so I have a question...many of the lowend graphics cards that we all use...cuz were cheap or dirt poor lol me....have only 512 mb of memory....i got mine OCed to about 658 mb....would that be more than enough for dolhpin and how much would this make the overall temperature of the graphics card go up cuz i got mine to sit at a steady 70-80 C depending on the surface it is placed on...anymore and iw ould have to underclock cuz i dont want it to go bad.
(10-06-2010, 06:12 AM)hansenderek Wrote: [ -> ]have only 512 mb of memory....i got mine OCed to about 658 mb
lol
Sorry, but true.
You better revert all overclocking stuff you have done because you really don't know what you are talking about and you don't understand, what you do with your hardware.
And BTW: your question is far far away from topic of this thread.
Quote:have only 512 mb of memory....i got mine OCed to about 658 mb
You can't increase memory capacity by overclocking......that would require adding more transistors on a nanoscopic level. Also the framebuffer on the wii is only 2MB. Even at 1080p it should use less than 25MB of space in the vdram. Considering dolphin almost never uses more than 200-300MB of vdram even at 1080p you should be fine.
Quote:would that be more than enough for dolhpin and how much would this make the overall temperature of the graphics card go up cuz i got mine to sit at a steady 70-80 C depending on the surface it is placed on
Should barely go up at all. We are simply proposing that we store the efb as an fbo in vdram. Which would only increase the utilization of the vdram and imc, not sp.
Quote:And BTW: your question is far far away from topic of this thread.
Actually his question is completely on topic. He's asking how our proposed changes to the efb copy system would affect gpu temperature/video memory consumption. How is that off-topic in any way?