Search results

correct. but with clamp-to-edge you can still use the end rows/columns of your atlases, which is what i originally assumed your concern was with. my bad if i misunderstood that.

in case you're referring to wrap-around artifacts, you can use clamp-to-edge addressing mode to avoid that. it's part of the ES core spec thus is universally supported.

i'm a brown cow and i officially approve of this thread. with this annex too.

yes. and then some.

not meaning to argue or anything, but even software blitters care about things like cache-line sizes, and those come in, well, you guessed it.. /more power to 2!

just wanted to note that the above may not be such a big deal, depending on the effective bpp of the SGX tile buffer in this case. from what i remember, PVR have historically had true color tile buffers, so all fb blend operations work at 24/32bpp fidelity, and any color downgrading happens...

while i'd normally be the first to defend sane compiler tech, i'll very much advise against relying on that here. while certain cases may be fine with Imagination's compiler, they may fall flat under other GLSL compilers. generally, throwing unnecessary work at your shaders (i.e. things you can...

that's better now. a final remark from me. generally no. not because it's slower per op, but it's work carried *per vertex*. like in your current vertex shader - that matrix-by-matrix multiplication you do there is done at every vertex - you need to take this out of the shader and place it into...

I agree that figuring one's way in OLG could be an endeavor for any newcomer. OGL is an API with a long history, in a field that has evolved repeatedly, particularly lately. That said, this page should be on a quick-dial in your bookmarks ; ) You may want to check out the GLSL ES specification...

Good first attempt at it, B-ZaR. Unfortunately it's not quite fixed-function-free yet - you still use the matrix stack (glLoadIdentity, etc) and your vertex shader uses a legacy gl_* state stemming from the matrix stack (gl_ModelViewProjectionMatrix). Additionally, you use legacy vertex...

Thanks for the offer, I'll surely pester you with pointless code build requests. What IRC do pandoreans frequent, btw? Well, the current extension set is not exactly earth-shattering, by I tend to follow the 'half-full' philosophy, so things like GL_OES_vertex_half_float GL_OES_texture_float...

Unfortunately I'm yet as pandora-less as the best of them. But I've been using paeryn's services to run some code on the panda. Apropos, if you unspoiler the second spoiler in that post you might see interesting things about the current SGX driver edge. Re that extension, I have the gut feeling...

Are you referring to GL_IMG_texture_stream2? It appears to be in the current drivers. But the only meaningful information I could find about it was this TI code...

new version * depth testing disabled, along with depth and stencil buffer clearing, for cleaner shader-performance results * added build script for cross-compiling for pandora; compile options courtesy of paeryn * put XRANDR use on conditional compile (currently disabled in the pandora script)...

That's a good beginning, torpor. I'm really curious to see what will be pandora's soundscape in the near future ; )

Well, test is GPU-centric and performance should be largely CPU-clock-independent. System buses and GPU-domain clocks are a different matter altogether. I spent some time pondering on the stencil subject. Actually, a TBR could just as well benefit from not clearing it (when not needed) just...

7aeb1c0cbc50664e70e0ab82b9a5df6c

ED, i kindly ask you to stop wasting your precious time in treads like this one. unless you do that on the background while waiting for something tedious to finish, that is (this is how i mostly do my forum dwelling). but generally, the very idea of an OPT member visiting this thread was a bad...

Thanks for the feedback, paeryn. BTW, I just noticed an overlook in the benchmark that could hurt TBRs - I did not bother to clear the stencil buffer at the start of each frame (a benign, or even beneficent, condition for IMRs, but likely hurting TBRs). Moreove that judging from the logs the app...

Cheers, paeryn! Also, excellent sleuthing work there - thanks! So the test yielded 18FPS at 256x256 - that's not bad for a mobile GPU. The standard derivatives extension is also functional (assuming the normal mapping in the test looked ok). The only downside from the test is the slightly low...