pouët.net

hermes: With our cores (the ARM Mali-series), there's no cost in using NPOT-textures for normal texturing, at least.

Ah the joys of FBO, RBO, MSAA... could've been in fucking chinese for all I know. :-)

kusma, you are responsible for those mali things?
just let me tell you how much i hate them, especially compared to an nv apx! :)

@shiva: The nice thing to about the Tegra APX is that it's powered by an ARM 11 :)

I can try if by "render buffer objects" you understand everything what was proposed in pbuffer and render_texture extensions. Mostly the difference is that FBO's are not window system dependent and that makes them the best oprion when you port your apps. Next thing is that when using FBO's you can completely forget about switching contexts - which sometimes hurts a lot but actually they were really hard to handle. I switched to FBO's 3,5 years ago because I was ultra pissed by wglShareLists, which back then worked really randomly. And whenever I was trying to do shadow mapping I had to share those lists. But what's most important. "render buffer objects" are no longer supported so whenever you will want to use MRT or some kind of special antialiasing like coverage multisampling you'll need to switch to FBO's. They are really great and you'll find all the common scenarios of usage directly in the extension description as examples.

thanks bonzaj,

I spent some hours last night trying to figure out what's going on with these things. I would get render to texture but not multisampling, and then multisampling but not depth buffers. Anyway it is all working now (I think!) and I hope I can move away from pbuffers.

I was quite annoyed to find very little reference online on all this, especially the error messages. But then again at some point I was searching them as "Flexible buffer objects" rather than "Frame buffer objects" (I was very sleepy)

I also use them on opengl for ages and the only problem I have on my really old laptop is that they don't tile, but that's nothing a shader can't handle. I don't know anything about performance, but were we supposed to code screen effects in any other way? :S

*screen space

"don't tile"?

just one note, switching (binding/unbinding) FBOs is very slow in Vista today. So instead of creating as many FBOs as renderable textures you have, I recommend creating one single FBO in the engine, and then just do the right color/depth attachments to it as needed, what for some reason is much faster than the other (and natural) way.

And good luck dear OpenGL API user, setting up MRT with Antialiased Float16 buffers can be a nightmare...

shiva: I'm partly responsible for the OpenGL ES drivers, yeah.

lazy-san: have you read the part in the d3d documentation called "width vs pitch"? the pitch can change from "width*pixelsize" for various reasons.

however, that does not mean that your texture is artificially inflated to the next power of 2 when you're using it or that the rest of the space is blank. it just means that the allocator will pack things in memory in certain ways. probably because power of 2 textures are most common it makes sense to optimise for them to avoid wasting too much space. there certainly are rules about alignment for starting locations of surfaces.
the texture is still the size you asked for even if the pixels are not all contiguous in linear memory. in 2d they're still together. :)

gargaj: GL_REPEAT doesn't work, only GL_CLAMP

Tiago: can't be - you need to be doing sth wrong. I just checked it and it tiles all right.

Tiago uses that old shitty nv extension, it seems

I don't know. Maybe it was something else then, but I just need them for screenspace things.

From what I remember it worked, but a few times slower. It's not important.

iq: if that's what I do naturally just by reading extension specs and such that's what every decent human being should do (the FBO / RBO / render to texture stuff). Why would someone write 2 lines of code when they can just write 1?

1 line of code, with less chars than the 2 lines of code... less characters is less pain. Coding is boring. Look at Stephen Hawking. He's so lazy he only uses a finger to code.

They should have used a full ARM11 MPCore though (4 cores instead of one)..

the discussion was about the gpu, not the cpu.
the tegra has a geforce based gpu which is nicer than the mali gpu by arm.
they usually put the gpu and cpu on the same chip though, but afaik the arm11 cpu is maybe 10% of a tegra.
doesn't matter that the cpu is an arm 11 or cortex or whatnot.

reading all this, you must really hate OpenGL.

we do

@jar_: I was just being an asshole :) And to come clean! My desk is about 5 meters away from Kusma's.

shiva: What do you put into "nicer"?

It's not the size of the texture.. it's what you do with it!