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.

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:

Graphics3D 800,600,16,2

Const FPS=30

cam=CreateCamera()
	CameraRange cam,.01,200
	PositionEntity cam,0,0,-4
	CameraClsColor cam,0,0,100

c=CreateCube()
	EntityFX c,1

;texture:
;try with and without 256 flag
tex=CreateTexture(512,512,1+256)
	EntityTexture c,tex
;----------------------------------------

period=1000/FPS
time=MilliSecs()-period
MoveMouse 320,240

While Not KeyDown(1)

	;------ Framerate Counter ----------
	fps_count=fps_count+1
	fps_timer=fps_timer+(MilliSecs()-fps_millis)
	fps_millis=MilliSecs()
	If fps_timer>1000
	fps_timer=0:fpsc=fps_count:fps_count=0
	EndIf
	;---------------------------------------


	;---
	Repeat
		elapsed=MilliSecs()-time
	Until elapsed

	;how many 'frames' have elapsed	
	ticks=elapsed/period
	
	;fractional remainder
	tween#=Float(elapsed Mod period)/Float(period)
	
	For k=1 To ticks
		time=time+period
		If k=ticks Then CaptureWorld
	;---

	TurnEntity c,.1,.2,.3

	If KeyDown(200) MoveEntity cam,0,0,.2
	If KeyDown(208) MoveEntity cam,0,0,-.2
	If KeyDown(203) MoveEntity cam,-.2,0,0
	If KeyDown(205) MoveEntity cam,.2,0,0
	TurnEntity cam,MouseYSpeed()/6.0,-MouseXSpeed()/6.0,0
	RotateEntity cam,EntityPitch(cam),EntityYaw(cam),0
	MoveMouse GraphicsWidth()/2,GraphicsHeight()/2

	Color 50,50,0:Rect 0,0,512,512,1
	For a=1 To 40
		Color Rand(0,255),Rand(0,255),Rand(0,255)
		Rect Rand(20,500),Rand(0,500),Rand(2,100),Rand(2,100),1
	Next
	Color 0,0,0:Rect 0,0,512,512,0:Rect 1,1,510,510,0:Rect 2,2,508,508,0
	CopyRect 0,0,512,512,0,0,BackBuffer(),TextureBuffer(tex)
	
	UpdateWorld
	
	;---
	Next
	;---
	
	RenderWorld tween
	
	Color 255,255,255
	Text 10,10,"fps:"+fpsc
	
	Flip
Wend
End

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.



That doesn't mean it's not a driver issue. It just means it's a driver issue you have live with.



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.