08-02-2011, 06:53 AM
Pages: 1 2
08-02-2011, 06:56 AM
08-02-2011, 07:10 AM
08-02-2011, 07:11 AM
08-02-2011, 07:28 AM
08-02-2011, 07:48 AM
08-02-2011, 07:56 AM
08-02-2011, 08:13 AM
Do you even understand why the option was there in the first place? If not, hope for NaturalViolence to explain it to you 
Explaining why it was removed is pointless if you don't even know that anyway.
Explaining why it was removed is pointless if you don't even know that anyway.
08-02-2011, 02:32 PM
08-02-2011, 08:12 PM
Meh, let's get this straight: I'm just trying to find a way to get around learning for my exams
So here we are, having no clue about the Wii's hardware architecture or what a texture cache is. Awesome
(note that I'm using the term "CPU RAM" pretty wrongly here, since the CPU doesn't have any RAM by itself - but you get the idea)
(also note that whenever I'm referring to the Wii, it also applies to the GC, since the graphics processors in both are almost identical)
The Wii stores all kinds of data which PC hardware stores in video RAM (on the GPU) merely in normal RAM - in fact, the Wii's VRAM is only about 4 MB (or 3 MB? no idea) big and only contains framebuffer data (the stuff where your 3d graphics get rendered to). EVERYTHING else - that is e.g. vertex data and textures - is stored in RAM. With PC hardware, this would be a huge bottleneck due to the slow bandwidth between CPU RAM and video RAM (i.e. transfering data on each access is SLOW), but it's easily doable on console hardware since we have an incredibly fast bandwidth there. Thus, each time the GPU needs to access data, the data is being transfered from CPU RAM to some local GPU cache.
This also means that the CPU can directly modify textures without rendering at all. Just tell your CPU to modify some byte and be done, since the GPU will re-fetch the texture data on the next render process anyway. This is a major difference to the "conservative" Direct3D/OpenGL programming model on a PC - there, you need to "lock" textures if you want to modify them and "unlock" them once you're done. However, both steps are linked with a huge performance penalty since they require transfering data between CPU and GPU RAM. Not so on the GC/Wii
So let's repeat this - the CPU can modify any texture data any time and the GPU will automatically make use of the new texture data on the next frame. And texture data can be stored anywhere in RAM.
But how does this affect emulation? Quite a bit, since we somehow have to (in layman's terms) emulate the console programming model with the PC programming model (including the API limitations we get from Direct3D and OpenGL). So the naive approach would be to just reload the textures each time they're used in a rendering process - possible and easiest, but note that the Wii's textures are stored in a different format than the formats used by Direct3D and OpenGL. Thus before actually applying our "emulated textures", we need to decode the texture data from the emulated RAM memory. And that, if done every time a texture is used, is awkwardly slow. Thus some sort of caching is needed if a decent level of emulation speed is wanted.
The main problem with caching stuff is - how do we detect texture changes so that we know when to update our cache? This is pretty hard since (I tend to repeat this) the CPU stores texture data anywhere and can modify it any time - there's no specific RAM area which we could simply track for changes on each CPU instruction call.
Long story short, what we do is: Whenever the GPU is asked to render stuff, we check what textures are currently bound to the GPU pipeline. If those textures have never been used before, decode them from RAM and store them in a D3D or OGL texture object. Additionally, a hash* of the texture data inside that texture is created from the source RAM data.
In case we check for what textures are currently bound to the GPU pipeline and we find out that the texture HAS been used before, we already have an entry in our texture cache for it. To check if the data was modified, we create a hash for the new RAM data and compare it to the hash of the RAM data which was used to load our texture. If they match, just reuse the texture, if they differ, decode and reload the texture from RAM.
* What is a hash? Frankly said, it's a 64-bit number which is used to almost-uniquely identify a large chunk of memory. I.e. if you change only one byte of a texture, you ideally end up with a different hash.
Obviously, the most critical part of this is creating the hash - you need a fast algorithm for hash creation, since the speedup from caching is then lost. But you also need a unique hash, otherwise you'll lose some texture changes, which gets visible since some textures on the screen won't update properly - think of the spinnnig coins in New Super Mario Bros. Wii (although some other effects play a role there). Because of this, we had that texture cache slider until Dolphin 3.0. The rightmost (fastest) setting was special, but I won't go into more detail about that. The other three options specified the amount of samples of a texture to use for hashing. I don't know the exact values, but it boils down to sth like "if fast texture cache is used, just calculate the hash based upon a quarter of all pixels in the texture" and "if safe texture cache is used, calculate the hash based upon ALL pixels in the texture". The more pixels you use for hash calculation, the less likely you are to miss any texture changes, but performance will also suffer from that.
But what does the rewritten texture cache do different? About everything, but the principle is the same. And, actually, it would be perfectly possible to implement a "fast texture cache" (referring to the hash calculation) there as well. It just was decided that forcing safe hash calculation apparently was the best way to go.
Think you understand how textures work on the Wii now? Meh, keep dreaming. There sure is enough other stuff to know
So here we are, having no clue about the Wii's hardware architecture or what a texture cache is. Awesome
(note that I'm using the term "CPU RAM" pretty wrongly here, since the CPU doesn't have any RAM by itself - but you get the idea)
(also note that whenever I'm referring to the Wii, it also applies to the GC, since the graphics processors in both are almost identical)
The Wii stores all kinds of data which PC hardware stores in video RAM (on the GPU) merely in normal RAM - in fact, the Wii's VRAM is only about 4 MB (or 3 MB? no idea) big and only contains framebuffer data (the stuff where your 3d graphics get rendered to). EVERYTHING else - that is e.g. vertex data and textures - is stored in RAM. With PC hardware, this would be a huge bottleneck due to the slow bandwidth between CPU RAM and video RAM (i.e. transfering data on each access is SLOW), but it's easily doable on console hardware since we have an incredibly fast bandwidth there. Thus, each time the GPU needs to access data, the data is being transfered from CPU RAM to some local GPU cache.
This also means that the CPU can directly modify textures without rendering at all. Just tell your CPU to modify some byte and be done, since the GPU will re-fetch the texture data on the next render process anyway. This is a major difference to the "conservative" Direct3D/OpenGL programming model on a PC - there, you need to "lock" textures if you want to modify them and "unlock" them once you're done. However, both steps are linked with a huge performance penalty since they require transfering data between CPU and GPU RAM. Not so on the GC/Wii
So let's repeat this - the CPU can modify any texture data any time and the GPU will automatically make use of the new texture data on the next frame. And texture data can be stored anywhere in RAM.
But how does this affect emulation? Quite a bit, since we somehow have to (in layman's terms) emulate the console programming model with the PC programming model (including the API limitations we get from Direct3D and OpenGL). So the naive approach would be to just reload the textures each time they're used in a rendering process - possible and easiest, but note that the Wii's textures are stored in a different format than the formats used by Direct3D and OpenGL. Thus before actually applying our "emulated textures", we need to decode the texture data from the emulated RAM memory. And that, if done every time a texture is used, is awkwardly slow. Thus some sort of caching is needed if a decent level of emulation speed is wanted.
The main problem with caching stuff is - how do we detect texture changes so that we know when to update our cache? This is pretty hard since (I tend to repeat this
) the CPU stores texture data anywhere and can modify it any time - there's no specific RAM area which we could simply track for changes on each CPU instruction call.Long story short, what we do is: Whenever the GPU is asked to render stuff, we check what textures are currently bound to the GPU pipeline. If those textures have never been used before, decode them from RAM and store them in a D3D or OGL texture object. Additionally, a hash* of the texture data inside that texture is created from the source RAM data.
In case we check for what textures are currently bound to the GPU pipeline and we find out that the texture HAS been used before, we already have an entry in our texture cache for it. To check if the data was modified, we create a hash for the new RAM data and compare it to the hash of the RAM data which was used to load our texture. If they match, just reuse the texture, if they differ, decode and reload the texture from RAM.
* What is a hash? Frankly said, it's a 64-bit number which is used to almost-uniquely identify a large chunk of memory. I.e. if you change only one byte of a texture, you ideally end up with a different hash.
Obviously, the most critical part of this is creating the hash - you need a fast algorithm for hash creation, since the speedup from caching is then lost. But you also need a unique hash, otherwise you'll lose some texture changes, which gets visible since some textures on the screen won't update properly - think of the spinnnig coins in New Super Mario Bros. Wii (although some other effects play a role there). Because of this, we had that texture cache slider until Dolphin 3.0. The rightmost (fastest) setting was special, but I won't go into more detail about that. The other three options specified the amount of samples of a texture to use for hashing. I don't know the exact values, but it boils down to sth like "if fast texture cache is used, just calculate the hash based upon a quarter of all pixels in the texture" and "if safe texture cache is used, calculate the hash based upon ALL pixels in the texture". The more pixels you use for hash calculation, the less likely you are to miss any texture changes, but performance will also suffer from that.
But what does the rewritten texture cache do different? About everything, but the principle is the same. And, actually, it would be perfectly possible to implement a "fast texture cache" (referring to the hash calculation) there as well. It just was decided that forcing safe hash calculation apparently was the best way to go.
Think you understand how textures work on the Wii now? Meh, keep dreaming. There sure is enough other stuff to know
Pages: 1 2