Jump to content

  • Log In with Google      Sign In   
  • Create Account

Banner advertising on our site currently available from just $5!


1. Learn about the promo. 2. Sign up for GDNet+. 3. Set up your advert!


Large textures are really slow...


Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • You cannot reply to this topic
39 replies to this topic

#21 blueshogun96   Crossbones+   -  Reputation: 1536

Like
0Likes
Like

Posted 01 March 2014 - 10:26 AM

 


Yea I forgot about alpha test. The overlay you missed my point completely.

.5*healthbar + .5*your_background texture   ==  .5*your_background texture + .5*healthbar

If you put the background drawn first, without alpha blending, it will be in the background. If you blend your health bar on top, the amount of pixels you are blending is only the health bar pixels. (A lot less pixels blending).

 

I'm not sure that would work that well...

 

Maybe with constant alpha, but not with an alpha channel.

 

First you would also need to modify your blending function, and make sure your framebuffer is RGBA.

 

Normally you do srcA * srcRGB + (1-srcA)*dstB.

 

If you want to to it the other way around, you have to blend with (1-dstA)*srcRGB + dstA*dstRGB in your second pass, to use the alpha in the overlay.

 

I think It also requires that the game graphics can't have an alpha channel of their own, so no smooth edges. (like those clouds)

 

Okay, now I see what he was trying to say.  Still not sure that would work for reasons already said.

 

Shogun.


Follow Shogun3D on the official website: http://shogun3d.net

 

blogger.png twitter.png tumblr_32.png facebook.png

 

"Yo mama so fat, she can't be frustum culled." - yoshi_lol

 

"One objection to a “critique of C#” would be that you can’t talk about C# without talking about the whole “.Net experience”. However, one can approach the topic of Hitler without a complete discussion of Nationalist Socialism, so I feel justified." - Steve White.


Sponsor:

#22 blueshogun96   Crossbones+   -  Reputation: 1536

Like
0Likes
Like

Posted 01 March 2014 - 10:28 AM

 


I've never heard of texturetool.  Does it come with XCode or something?  Let me google that.

 

https://developer.apple.com/library/ios/documentation/3DDrawing/Conceptual/OpenGLES_ProgrammingGuide/TextureTool/TextureTool.html

 

Wow, sir, you respond quick! :)

 

Unfortunately, I don't have Mavericks installed right now, so I don't have the iOS7 SDK.  If I upgraded to Mavericks through the App Store, would all of my files be left in tact?  Or do I have to reinstall everything?

 

Shogun.


Follow Shogun3D on the official website: http://shogun3d.net

 

blogger.png twitter.png tumblr_32.png facebook.png

 

"Yo mama so fat, she can't be frustum culled." - yoshi_lol

 

"One objection to a “critique of C#” would be that you can’t talk about C# without talking about the whole “.Net experience”. However, one can approach the topic of Hitler without a complete discussion of Nationalist Socialism, so I feel justified." - Steve White.


#23 swiftcoder   Senior Moderators   -  Reputation: 13224

Like
0Likes
Like

Posted 01 March 2014 - 10:35 AM


Unfortunately, I don't have Mavericks installed right now, so I don't have the iOS7 SDK.

It is in the previous SDKs too.


Tristam MacDonald - Software Engineer @Amazon - [swiftcoding]


#24 blueshogun96   Crossbones+   -  Reputation: 1536

Like
0Likes
Like

Posted 01 March 2014 - 10:45 AM

Okay, I'll get going on that ASAP.

 

Shogun.


Follow Shogun3D on the official website: http://shogun3d.net

 

blogger.png twitter.png tumblr_32.png facebook.png

 

"Yo mama so fat, she can't be frustum culled." - yoshi_lol

 

"One objection to a “critique of C#” would be that you can’t talk about C# without talking about the whole “.Net experience”. However, one can approach the topic of Hitler without a complete discussion of Nationalist Socialism, so I feel justified." - Steve White.


#25 TheChubu   Crossbones+   -  Reputation: 6408

Like
0Likes
Like

Posted 01 March 2014 - 11:06 AM

There is also the Imagination Technologies SDK, it has a texture tool too, with various compression formats (including PVRTC). And it looks that it works on pretty much anything (Linux, Mac, Windows).

 

You need to register an (free) account to download it though.

 

http://www.imgtec.com/powervr/insider/sdkdownloads/index.asp

 

I wanted it for DXT compression and I haven't tried it yet (fighting with mesh loading now) but it looks useful.


"I AM ZE EMPRAH OPENGL 3.3 THE CORE, I DEMAND FROM THEE ZE SHADERZ AND MATRIXEZ"

 

My journals: dustArtemis ECS framework and Making a Terrain Generator


#26 tanzanite7   Members   -  Reputation: 1384

Like
0Likes
Like

Posted 01 March 2014 - 12:46 PM

Alpha testing on mobile devices is generally slower, and should be avoided.  This is what I've read many times while googling iOS optimizations.  Second, I'm using OpenGL ES 2.0, and it doesn't appear that GL_ALPHA_TEST is supported.  Gives me an error when I try to enable it because it's not defined.

Alpha test interferes quite badly with early depth testing on typical hardware - however, you do not need nor benefit from early depth testing anyway (as far as i can see from the picture posted).

Alpha testing, the ancient silly way ("enable(GL_ALPHA_TEST)"), is deprecated (ie. not to be confused with not supported) - it should be done in shader directly (ie. "discard").

It cuts down bandwidth from areas that are hard or impossible to efficiently reach with the geometry approximations - in short, it might be worth experimenting with (although "discard" might be slightly costly [with no depth test] on amazingly-badly-engineered-garbage-hardware ... to be fair, i do not know if mobile devices do qualify for that title or not. So, might be of no use to you, but i thought i clarify the alpha test anyway).

#27 Olof Hedman   Crossbones+   -  Reputation: 3603

Like
0Likes
Like

Posted 01 March 2014 - 04:13 PM


It cuts down bandwidth from areas that are hard or impossible to efficiently reach with the geometry approximations - in short, it might be worth experimenting with (although "discard" might be slightly costly [with no depth test] on amazingly-badly-engineered-garbage-hardware ... to be fair, i do not know if mobile devices do qualify for that title or not. So, might be of no use to you, but i thought i clarify the alpha test anyway).

 

Discard is indeed a bit expensive on a lot of mobile hardware, but to be fair, you have to cut some corners when you have just about a square inch and a few watts to work with!



#28 dpadam450   Members   -  Reputation: 1252

Like
0Likes
Like

Posted 01 March 2014 - 05:36 PM

Thread is kind of long for a simple problem. I will leave with this though:

 

 

First you would also need to modify your blending function, and make sure your framebuffer is RGBA.

No.......   If you are blending any 2 images. As you pointed out SRC, and inverse of source.
Green Texture in Framebuffer,  I apply a red sprite on top with .2 alpha,        (0,1,0)*(1.0-.2)    + (1,0,0)*(.2) = (.2, .8,0)

Ok throw the red spirte in the framebuffer and blend the green like the OP is doing:
Red sprite in Framebuffer, I apply the green overlay with .8 alpha over it,     (1,0,0)*(1.0-.8)  +  (0,1,0)*(.8) = (.2,.8,0)

Definitely worth a try. When there are several different sprites drawn at the same location, you may get unintended results, depends on what they look like, and depends on how many sprites you really have layered.



#29 Olof Hedman   Crossbones+   -  Reputation: 3603

Like
0Likes
Like

Posted 02 March 2014 - 03:44 AM

Sure, but how would the sprite know what alpha to use?

 

That level is defined in the alpha channel of the overlay. If the sprite moves (which sprites usually do), it would need to use another alpha if you want to draw it on top and get the same result as if you drew it below.

 

So you need to use destination alpha instead of source, and can't have an alpha channel in the sprite too.


Edited by Olof Hedman, 02 March 2014 - 06:10 AM.


#30 tanzanite7   Members   -  Reputation: 1384

Like
0Likes
Like

Posted 02 March 2014 - 05:37 AM

Discard is indeed a bit expensive on a lot of mobile hardware, but to be fair, you have to cut some corners when you have just about a square inch and a few watts to work with!

 

 

I did a bit or reading about how mobile devices do things, but did not get any smarter in regards to their "discard" - every time they told that discard can be detrimental to performance they did so in regards to hidden-surface-removal/early-depth testing (which is the obvious disaster-case regardless of hardware - and likely to hit tiny-die devices especially hard).

 

Which keep the question open - does it degrade performance if no depth testing is used? I can not think of any reason why it should/could.



#31 swiftcoder   Senior Moderators   -  Reputation: 13224

Like
0Likes
Like

Posted 02 March 2014 - 08:48 AM


Which keep the question open - does it degrade performance if no depth testing is used?

Degrade performance as compared to what, exactly? I see a few alternatives to discard: (a) not drawing the pixels in the first place via geometry changes, (b) blending the pixels with zero alpha, © rejecting the pixels with the stencil buffer, or (d) rejecting the pixels with the depth test.

 

Option (a) is pretty much always going to win on mobile hardware, followed closely by (d) and then ©. Option (b) is likely to be worse than discard, but I wouldn't expect significant gains.


Tristam MacDonald - Software Engineer @Amazon - [swiftcoding]


#32 tanzanite7   Members   -  Reputation: 1384

Like
-1Likes
Like

Posted 02 March 2014 - 03:25 PM

Reread OP:

 

"One of my main game features (visually) is the overlay texture I'm using.  This overlay texture is full screen, and covers the entire screen which gives it a nice transparent pattern."

 

And the post following it:
 

"http://shogun3d.net/images2/looptil/04.jpg"

 

Depth test is absolutely useless there - as i mentioned in my original post. I take you did not read any of it.



#33 joew   Crossbones+   -  Reputation: 4133

Like
2Likes
Like

Posted 02 March 2014 - 05:42 PM


Alpha testing, the ancient silly way ("enable(GL_ALPHA_TEST)"), is deprecated (ie. not to be confused with not supported) - it should be done in shader directly (ie. "discard").

It cuts down bandwidth from areas that are hard or impossible to efficiently reach with the geometry approximations - in short, it might be worth experimenting with (although "discard" might be slightly costly [with no depth test] on amazingly-badly-engineered-garbage-hardware ... to be fair, i do not know if mobile devices do qualify for that title or not. So, might be of no use to you, but i thought i clarify the alpha test anyway).

discard is actually destructive on nearly all current mobile chips and should be avoided at all costs, especially if you are targetting mobile devices that are a few years old. There is always a better way (performance-wise) even if some are slight asset hacks. Also null blends are vastly cheaper than using discard at least on PVR chips.


Edited by joew, 02 March 2014 - 05:45 PM.


#34 swiftcoder   Senior Moderators   -  Reputation: 13224

Like
0Likes
Like

Posted 02 March 2014 - 06:10 PM


Depth test is absolutely useless there - as i mentioned in my original post. I take you did not read any of it.

You are missing the point of my post: there are many methods to reject pixels, and there is no magic bullet.

 

Asking whether discard degrades performance is a subjective question. What are we comparing it to? The performance of not discarding pixels? The performance of using another pixel rejection path?


Tristam MacDonald - Software Engineer @Amazon - [swiftcoding]


#35 joew   Crossbones+   -  Reputation: 4133

Like
1Likes
Like

Posted 02 March 2014 - 11:48 PM

On PowerVR chips simply using discard even once in a single shader will disable a lot of optimizations hence the larger than normal performance hit. For devices using PVR you want to optimize your geometry as much as possible avoiding overdraw, and at the same time remember that alpha blend is nearly free due to the way the TBDR renders, whereas rejection using discard or depth testing is costly.

#36 tanzanite7   Members   -  Reputation: 1384

Like
0Likes
Like

Posted 03 March 2014 - 04:42 AM

Gamedev forum software broke again - cannot use any formatting.

 

--------------------------

joew: "discard is actually destructive on nearly all current mobile chips and should be avoided at all costs, especially if you are targetting mobile devices that are a few years old. There is always a better way (performance-wise) even if some are slight asset hacks. Also null blends are vastly cheaper than using discard at least on PVR chips."

 

Thanks for actually addressing the question. Just to clarify, did you mean that "null blends are vastly cheaper than using discard when depth (and stencil) testing is disabled"? As thous would obviously be hurt quite badly by discard.

 

swiftcoder: "You are missing the point of my post: there are many methods to reject pixels, and there is no magic bullet.

Asking whether discard degrades performance is a subjective question. What are we comparing it to? The performance of not discarding pixels? The performance of using another pixel rejection path?"

 

If you would have read my relevant post then you would have known exactly what the question was meant to compare - and hence know that you do not HAVE a point. _Not relevant to the question anyway_.

 

To recap for your benefit (post #26 onwards): "It might be worth using discard after doing everything else (geometry approximation in particular) given that depth test is unusable. Hm, not sure how much of an impact discard has under thous circumstances - reading around about mobile devices did not clear the question, does anyone know?"



#37 joew   Crossbones+   -  Reputation: 4133

Like
0Likes
Like

Posted 03 March 2014 - 05:25 PM

Sorry what I meant was that it is better to actually alpha blend using 1.0 rather than using discard, but I worded it improperly calling it a null blend. Basically do everything humanly possible before resorting to using discard / depth testing on any PVR chipset, as well as a most other mobile GPUs (I don't have experience with the nVidia chips so I have no idea on those). As soon as the driver cannot rely on every pixel being drawn it is forced to take a more complex and therefore slower render path disabling many key TBDR optimizations.

 

EDIT: also looking at the problem set in this thread I would definitely recommend using tessellated geometry reducing the amount of overdraw as much as possible. I had to do this on a project that supported iPad1 as fill rate was not exactly ideal with that hardware. 


Edited by joew, 03 March 2014 - 05:28 PM.


#38 C0lumbo   Crossbones+   -  Reputation: 2931

Like
1Likes
Like

Posted 04 March 2014 - 12:24 AM

I think that tanzanite7 is getting frustrated because he's essentially asking the question:

 

"In a situation where HSR and early-z are not an option, is discard still bad?"

 

And he's getting a lot of answers about HSR and early-z.

 

TBH, I'd have to measure, but one possible reason that discard might be worse than the alpha blend in this scenario is that discard is adding a dynamic branch to the shader (by dynamic, I mean that some fragments within a 2x2 quad might take the discard path and others may not). However, I'd imagine that the relative costs are very hardware and shader dependent, I wouldn't be surprised if you could create a shader where discard clearly improves performance (e.g. if the shader was doing complex per pixel deferred lighting operations). However, I think that where you're just blending a simple texture onto the screen, then the cost of the discard probably outweighs the cost of the alpha blend.



#39 JohnnyCode   Members   -  Reputation: 540

Like
0Likes
Like

Posted 13 March 2014 - 01:57 AM

since you have a texture layed over screen to blend up to target, if I'm not mistaken, I came up with this idea that you could prerender it to the target stencil and blend it upon stencil test, what will allow you for early pre-rejection of pixel. Since stencil buffer is rather yes/no, you would not achive partial transparency, but maybe it would be a benefit, since you would reject totaly transparent parts, and alphablend only those partial ones. Maybe a crazy idea, I know, but you could try it and see, since it demands the texture transparency rendered to stencil only once, if you will not clear the stencil and use it for something else during frame.



#40 L. Spiro   Crossbones+   -  Reputation: 18934

Like
3Likes
Like

Posted 14 March 2014 - 08:31 AM

iOS uses a TBDR (tile-based deferred rendering) architecture which fully eliminates the need for sorting to reduce overdraw, but as has been mentioned the use of discard anywhere in a shader, blending, alpha-testing, and writing to gl_FragDepth forces this to be disabled, degrading performance significantly.
With blending, early-Z can still be used by the hardware (while not taking full advantage of TBDR), so it will still be your best first choice if available. Keep in mind that is modifies that depth buffer (should be no problem here).

Otherwise, alpha-testing and discard are almost identical, except that discard has the advantage of appearing earlier in the rendering path and potentially allowing a large portion of your shader not to be executed.
If you do use discard, remember to put it as close to the start of your shader as possible in order to discard as early as possible.

If you must use any of discard/alpha-testing, blending, or modified gl_FragDepth, trim the polygons to remove as many “whitespace pixels” from the rasterizing step as possible (this was already suggested and implemented). Another possibility is Z-prepass, in which the Z-buffer is prepared early via very simple no-lighting shaders with a very early discard; once this is done later passes can at least use early-Z.


L. Spiro

Edited by L. Spiro, 14 March 2014 - 08:37 AM.





Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.



PARTNERS