Flag 256 and Nvidia cards
Blitz3D Forums/Blitz3D Programming/Flag 256 and Nvidia cards
| ||
| Has anyone found a solution to the Nvidia cards not behaving properly with Texture Flag 256? Is there another solution available that allows fast texture access on Nvidia cards with Blitz3D ? Thanks in advance. |
| ||
| Which cards exactly? I think I heard something about 256 and ATI cards, but not with Nvidia, actually I have a GF2mx and it seems to work very well ... |
| ||
| I also use this flag without errors... |
| ||
| I have a Geforce2 GTS on one machine and a Geforce 256 on another. Flag 256 works on one (i.e. speeds things up) but on the other it's actually slower using flag 256. Can't remember which machine it doesn't work on, though - probably the 256. |
| ||
| Right. i dont know all the models, but on alot of nvidia cards the flag makes things crawl if you are drawing to texture ect, or it just doesnt perform the drawing operation at all. |
| ||
| Both of my nVidia cards crawl/get weird graphic because of it. Gforce MX2 64mb - (not surprising) nVidia 5200XT 128mb - doesnt crawl but graphic errors I would like to know why for sure. |
| ||
| I seem to remember jfk (I think) posted a code snippet that tests to see if your gfx card really supports flag 256. |
| ||
| Yeah .. i was curious if anyone had found a method of fast texture manipulation, as an alrernative to that flag. |
| ||
| My ATI would turn off mipmapping if the 256 flag was used, hence the slowdown. |
| ||
| It's to do with the memory usage. If you use that flag and force textures to stay in VRAM, they never get swapped out. So, more of everything else needs to get swapped. Works fine on my card though. |
| ||
| The 256 flag seemed to disable mip-mapping (causing a huge slowdown) on my old GeForce 2 card, just as it did for Shambler's ATI card. I wonder if this a "bug" with Blitz3D, or a Direct3D 7 incompatibility. |
| ||
| An utter noob question, but why wouldn't the driver handle VRAM automatically? eg. I've got 4 textures for a total of 1mb. Would these not be kept in VRAM anyway without me having to explicitly place them there? If I don't use the VRAM flag are the copied to VRAM every frame? |
| ||
| JohnJ, again, i think that's memory related. The 256 flag is forcing textures to remain put. ANd since mipmapping creates lower quality version of your textures, then that takes memory as well. Maybe mip mapping simply can't function if that flag is used. Maybe it's built into the card, that when textures are forced to remain in VRAM, then mip mapping gets disabled. Shifty, i believe textures are swapped to main memory if there isn't enough room. I've heard that been mentioned around here my people alot more knowledgable than me on the subject. Read it somewhere too. |
| ||
| That's what I understand, in which case the presence of textures in VRAM is dependant on the hardware's caching I guess. eg. if you have 48 mbs of textures in a scene and a 32 mb card, there'll be lots of data copying to VRAM. I guess if you had say a texture for the GUI you'd want to force this to remain in VRAM, so you'd use the VRAM flag. Is that the case, it's more of a 'Keep resident in VRAM' option? Otherwise I don't really understand the point of a load to VRAM flag as every texture ends up there anyway! |
| ||
| >Otherwise I don't really understand the point of a load to >VRAM flag as every texture ends up there anyway! It makes stuff like this faster http://www.blitzbasic.com/Community/posts.php?topic=47663&hl=mirror Andy |
| ||
| Shifty, 'Keep resident in VRAM' is basically what it is :o) |
| ||
| I think it will also be stored at a static adress in VRam, so you can access a single texel withou to mess up everything. Other textures, especially due to mipmapping, are managed dynamicly. If you want to edit a texel, the management is forced to update the whole texture. |
| ||
| The 256 flag seemed to disable mip-mapping (causing a huge slowdown) on my old GeForce 2 card, just as it did for Shambler's ATI card. I wonder if this a "bug" with Blitz3D, or a Direct3D 7 incompatibility. Pretty sure it's just a driver bug actually. I remember having this on my old gf2mx. I upgraded the drivers and it was much faster than without flag 256, as it should be. Of course, this was more than 2 years ago, so these would actually be very old drivers now. But I doubt any B3d code has changed in this area, so it probably is a driver issue. |
| ||
| A lot of people have old drivers, you have to handle it. |
| ||
| Definatly not a driver issue, not for every instance anyway. Many new cards with new drivers have issues when you use this flag in your blitz programs.. obviously nothing to be done for it directly. |
| ||
| For some actions it's the only way. So I'd suggest to test its speed and also if it works at all (some cards may leave the texture untouched when you try to copyrect etc. to it). When it works, use it, when it doesn't, simply skip the Effect. It was mentioned, I posted an example in the archives, although of course my code is kind of spahgetti, as usual :P the idea is there. (speed and texels checksum) |
| ||
| Ok now, this is kinda worrying me, I didn't know this was so frequent, much of my gameplay is based on writing things and getting clues from dynamically created textures ... damn it ... if this doesn't work properly then the whole game is a mess... Could you tell me if anyone get an absurd slowdown with this code (w/wo 256) or if anyone by any reason get nothing written to the texture??? you should only see some rects being drawn to the texture: |
| ||
| A lot of people have old drivers, you have to handle it. Was that addressed to me? I didn't suggest otherwise. I simply answered the question about what was causing it. All the evidence indicates that changes to drivers have caused it. Definatly not a driver issue, not for every instance anyway. Many new cards with new drivers have issues when you use this flag in your blitz programs.. obviously nothing to be done for it directly. That doesn't mean it's not a driver issue. It just means it's a driver issue you have live with. Could you tell me if anyone get an absurd slowdown with this code (w/wo 256) or if anyone by any reason get nothing written to the texture??? Approximately 1200 FPS ( with flip false ) with flag 256 Approximately 850 FPS ( with flip false ) without flag 256 Radeon 9700 Pro and recent-ish drivers. Both ways I see rects being drawn to the texture. |
| ||
| I'd say it's less than 10% of the cards that make troubles with flag 256. It won't make sense to start lots of tests. Simply do the checks as it was suggested to be on the save side. No Sybixsus, it wasn't adressed to you. I was talking about end users. A much more important question seems to be: will the support for this flag increase in future hardware (+ drivers) or is it gonna decrease. |
   |