Search results

You hit the nail on the head. A simple 'pld [dst]' inserted at the start of the main loop (chunks of 64 bytes) of Android's memcpy resulted in 4,582 MB/s (2x duplex BW) at 32KB arrays. That proves that the lack of write-allocate in L1D was indeed dictating the overall r/w performance in what I...

The irony is, the night I first ran the test I thought to myself, 'that BW should be doubled as it's a r/w test', and then I fell asleep. The thought of that did not return to me until you brought it up now. So yeah, all original numbers should be doubled. So, today I sat down to compose a...

My code is as straight-forward as it gets: unsigned r = kRepetitions; // we measure time through the clock_gettime() API, but we still want to aggregate individual tests for more robust measurements do { const unsigned chunk_size = 8 * (1 << 10); // chunks of 8KB, for the L1 case...

it's an iMX515 with 256KB unified L2. RAM is 512MB LPDDR on an 64-bit AMBA AXI bus, maxed at 200MHz, but in this case i suspect it might be run at 166/333 (i have not looked up the actual specs of the RAM chips). edit: nope, my bad - just checked some clock regs and DDR is actually run at...

I have a 32KB L1D/L1I-equipped A8, if something needs to be benchmarked.

make sure those 4800 quads are not individual draw calls - that amount of draw calls would easily kill many GL pipelines, let alone an embedded one. minimise GL state changes. state changes are increasingly expensive the weaker the CPU is.

FWIW, 16 is what the ipad drivers report as well.

was that reported in a new driver version? last time i saw those queried, they reported: GL_MAX_VERTEX_ATTRIBS: 8 note that these are a 4-component vector each, so you get 32 floats scalars worth of per-vertex attributes, altogether.

Farox, no doubt working 'virtually', without the hw can be extra tricky, perhaps prohibitively so if one is new to the field. But once you have your pandora i really doubt EGL or ES will be out of your skills. Just don't try to take it 'head on' - whenever in doubt, use the API documentation...

GL_MAX_TEXTURE_SIZE: 2048 GL_MAX_CUBE_MAP_TEXTURE_SIZE: 2048 GL_MAX_VIEWPORT_DIMS: 2048, 2048 GL_MAX_RENDERBUFFER_SIZE: 2048

right from a previous iteration of the matrix. indeed : )

promises are promises. gravedug.

in case you're referring to xdisplay being passed to glGetDisplay() - look closer at EGL::initGLES2() ; )

alternatively, you could just run it with the -screen parameter, which humbly resizes the app window on pandora ; ) topror, is that what you get when building under bullocks? can you add debug options to the build and check the backtrace in gdb? edit: ah, bad window surfice is what you get, i...

never seen that movie, but i've seen plenty of 'optimised' code which i wish had not been. the only thing worse than code written by people without adequate understanding of the task, is same code 'optimised' by those same people. the biggest 'early stage' optimisation i normally tolerate is...

hey Farox, for some reason the reading of the shader source files fails. Here's the respective line in the code: https://code.google.com/p/test-es/source/browse/app.cpp#693 (i do advise you to use this codebase, btw: https://code.google.com/p/test-es/ ) Make sure you have proper read...

it's a boys' thing.

is that some water-cooled ipad model i'm not aware of?

discount Fourier? are you by any chance a Lagrange disciple?

authoreyes, stop chemo-slacking and get back to business stat! : ) get well fast, man.