**** BEGIN LOGGING AT Sun Oct 16 02:59:57 2011 Oct 16 11:22:28 just to make sure i don't have a grave misunderstanding at this point: once glamo is up and running putting a bitmap on the display consists of nothing else but writing the bitmap data to the framebuffer memory region of the glamo? in the case of glamo with mmio the framebuffer _is_ a memory region? Oct 16 11:24:27 it is a memory mapped region yes Oct 16 11:25:51 the glamo is connected to the SoCs external memory bus Oct 16 11:30:56 ok. great. any idea if the glamo memory is accesible by the glamo core and the host bus at the same time? Oct 16 11:32:35 nope it isn't Oct 16 11:32:37 the glamo has two ram banks Oct 16 11:33:06 well, larsc for sure knows better detail Oct 16 11:33:25 iirc you can access one at the same from the host and glamo, but you can acess one from the host and one from the glamo core Oct 16 11:33:33 iirc you can't Oct 16 11:33:52 makes sense Oct 16 11:34:53 which access takes preference? Oct 16 11:35:28 but then one of both needs to be accessed for video-out at any arbitrary time (except VSYNC and HSYNC blank times) Oct 16 11:36:16 or is that "transparent" to the glamo engines? Oct 16 11:36:26 so to not block the host bus double buffering is pretty much necessary? Oct 16 11:37:12 the host bus can be used without the wait signal. so there must be some mechanism to interleave the memory accesses Oct 16 11:37:38 well, AIUI that's pretty much basics for all graphics adapters Oct 16 11:38:19 i suppose it would be an interesting experiment to add double buffering and have each buffer in one of the memory banks Oct 16 11:38:20 without buffering, you always get artifacts on display Oct 16 11:43:46 hmm. i guess at this point i really need a register dump of the runnning glamo. i still don't see why writing 40 full frames/s wouldn't be possible. Oct 16 11:44:38 what is the endianness of memwrite? Oct 16 12:11:47 meh the qtmoko kernel lacks /sys/devices/platform/glamo3362.0/regs Oct 16 12:11:58 does shr have it? Oct 16 12:53:41 to doublecheck wether i'm reading the registers correctly. no interrupts are enabled except for some reason the micro processors? Oct 16 19:25:05 quitte: on a recent DRM-enabled kernel, a command queue interrupt is used as well Oct 16 19:26:07 quitte: also, about accessing memory from host bus and Glamo at the same time: you can't access the exact same area, but you can tell Glamo to draw stuff at the "same" time as writing to it from the CPU.. i.e. no change of setup is needed, just a delay because of collisions Oct 16 20:24:03 quitte: for comparison, I could get about 48 frames/sec with negligible CPU load using the 2D engine and interrupt-driven fences: http://www.bitwiz.org.uk/openmoko/waitq.png Oct 16 20:33:39 Weiss: are you still working on it? Oct 16 20:36:53 not really Oct 16 20:37:04 sometimes I think I'd like to, though Oct 16 20:37:27 always think about it when i see the device lying around.. Oct 16 20:37:53 crying silently .o( give me a better ui .. give me wayland .. and gles1 ) Oct 16 20:38:55 but then i think about the mesa code base and tiling .. and all the hurdles Oct 16 20:40:36 the trouble with 3D stuff for me is just that there's so much to get perfectly right before anything even happens.. so it's unspeakably difficult to debug Oct 16 22:26:41 DieMumiee: of course, mainly I just don't have much time alongside work any more Oct 16 22:27:09 though, right now I'm putting what spare time I do have towards Project X (http://www.bitwiz.org.uk/s/2011/10/project-x.html) **** ENDING LOGGING AT Mon Oct 17 02:59:56 2011