Mipmapping and VRam resident not working 2gether?
Blitz3D Forums/Blitz3D Programming/Mipmapping and VRam resident not working 2gether?
| ||
| I tried to combine Flags 8 and 256 using texturefilters, but it seems as soon as I use Flag 256, mippmapping is ignored. Could it be that this is the nature of mipmapping? eg: cleartexturefilters texturefilter "",9 or 256 mesh=loadmesh("building.b3d") The reason why I tried this is DX tends to pause when it dynamicly loads surfaces/textures to vram, and this makes the framerate pretty jerky. |
| ||
| I think it works on some cards and not others. I know that if I enable VRam I lose mipmapping. |
| ||
| Flag 256 speeds things up on one of my PCs, and slows things down on the other!? :/ |
| ||
| Flag 256 speeds things up on one of my PCs, and slows things down on the other!? :/ Used to do that on one of mine too. Poor Nvidia drivers were the culprit. |
| ||
| Yes, I know. If you want to use it in a Release, first make a little benchmark test. I wrote some code that would test A] if it's supported at all (using a checksum test on the buffer) and B] if it's faster than non-256ish. Must be somewhere in the archives. Not a big deal. |
| ||
| Doesan't that make sense, since mipmapping creates a low-res version of the texture? If the texture were kept "real-time" it would have to create a new mipmap ever frame? |
| ||
| mipmapping is ok to prevent moire patterns, but I don't like the way how dx is "optimizing" Ram usage, since I got enough ram to hold everything in Ram, so no need to swap lots of versions over the bus and pause the game for .5s whenever I enter a new room. |
| ||
| Sybixus: that would explain it - I haven't updated the driver on the 'slow' machine for years. Didn't much see the point, it's only a GeForce 256. :/ jfk: Thanks. I'll have a root in the code arcs and see if I can find it. |
| ||
| Jo, If you use Flag 256 Flag 8 is allways disabled / have no effekt. |
| ||
| you will have to write a pixel to the texture each frame to trigger mipmap generation, that's what I made... |
| ||
| really? and then it keeps using vram resident textures? |
| ||
| VRAM resident textures are not meant for operations on them like a Mipmap replacement would be, only for being statically loaded. As Mipmap replaces the texture depending on the view distance, this would slow things down drastically ( try it youself. do some texture operations on a normal texture and on a +256 texture, the 2nd one will be 100-200x slower. Blitz3D has to copy the texture from VRAM into SysRAM, alter it and send it back to VRAM which needs quite some time ) big10p: try the 60.80 or 61.80 drivers at http://www.laptopvideo2go.com , they are top :) |
| ||
| only pixel shaders can change textures in VRAM. Pixel shaders only have read-access to textures. And their write position is pre-determined before pixel shader execution and not changable.(Hence pixel shader :) ) But, anyway, the fatest way is to just store a copy in local sysram. perform updates to that(And reads directly on the sys mem copy for v.fast performance) then just upload it. Uploading a 512x512 texture from sys ram to vid ram for example is v.fast. And on modern cards you can actually set the gpu's draw buffer to that of the texture's, using pbuffers. This doesn't work on a *lot* of older cards, but it's the fatest method. (not supported in b3d) |
| ||
| we are talking of Blitz3Ds VRAM flag not any new technics, perhaps you missed that? |
| ||
| How does you implying pixel shaders can write to textures, have anything to do with vram flag? |
| ||
| *never post 5 words that someone else could understand as a offer to write a lot of stuff that has nothing to do with the topic at all - so reedited the 5 words out* |
| ||
| Actually seinstein(not a typo), it was in reply to your further bit of factual fabrication where you stated a texture needs to be downloaded back into system ram to be edited. (You already have it in system ram, unless b3d supports render to texture, which it doesn't) So if I'm off-topic, so are you. But then I don't care what's on or off, i'm not that anal. |
| ||
| OK, I'm getting a bit confused here. :P TBH I don't really see what flag 256 is for - I thought all textures are kept in VRAM. When I LoadTexture() does Blitz not just load the texture into VRAM? Why do we need a flag to tell Blitz to store it in VRAM? I have a texture I need to re-draw every frame (a dynamic shadow map) so I assume I need to use flag 256 to keep the rendering as fast as possible, yes? Surely the GPU can only render to it's own memory (VRAM) and not sysmem? If so, I don't see the point of swapping stuff out to sysmem, other than if VRAM becomes full. Can someone explain to Mr. Thicko here what's going on! :P --- Thanks for the link Dreamora ;) |
| ||
| Without vram, blitz uses a managed mode. Which I believe is a case of performing ops in system memory, then uploading to vram. And also keeping textures in sys ram until referenced by a model, to help cards with low vid mem(I.e texture swapping. Whether mark's code does this or dx I dunno) But with vram flag, this managed mode is circumvented so that copyrects etc translate into(in gl terms, dx is not something I'm familar with) simple direct buffer copies from backbuffer to texture bufer (I.e no trip to system memory ala non v-ram flag mode, as color buffer/tex buffers are all agp side) I could be wrong, but if I am then I'm just as confused as you are to what it means ;) |
| ||
| 256 simply means the texture will always be in use and must not be paged etc... It is probably "kept alive" each cycle. mipmaps obviously won't work with 256 because 256 is a realtime texture and mipmaps are only generated when you load the texture. |
| ||
| Thanks for the answers, guys - I'm nearly there! :P Without vram, blitz uses a managed mode. Which I believe is a case of performing ops in system memory What kind of ops are you talking about here? Do you mean just stuff like CopyRect? Surely the texture has to actually be in VRAM in order for the GPU to perform other ops like Line, Rect, Oval etc.?! |
| ||
| There is no texture operation that you can perform over GPU in Blitz3D. All operations you perform on a texture are done over CPU in SysRAM which is the reason why VRAM + operations end in total break ins in performance if you want to use it in real time. |
| ||
| OK, so if I'm drawing to a texture every frame, I shouldn't use flag 256? BTW, I wonder how hard it would be for Mark to expand the GfxDriverCaps command so that it tells us whether flag 256 is supported or not. I currently only tells us if cube mapping is supported, doesn't it? |
   |