| 01:16.29 | *** join/#card10badge ebi_ (~quassel@dynamic-095-115-114-207.95.115.pool.telefonica.de) |
| 01:17.09 | *** join/#card10badge mkie (~quassel@dynamic-095-115-114-207.95.115.pool.telefonica.de) |
| 01:37.52 | *** join/#card10badge mkie (~quassel@dynamic-095-115-114-207.95.115.pool.telefonica.de) |
| 01:37.53 | *** join/#card10badge ebi_ (~quassel@dynamic-095-115-114-207.95.115.pool.telefonica.de) |
| 01:43.53 | *** join/#card10badge ebi_ (~quassel@dynamic-095-115-114-207.95.115.pool.telefonica.de) |
| 01:43.56 | *** join/#card10badge mkie (~quassel@dynamic-095-115-114-207.95.115.pool.telefonica.de) |
| 01:56.13 | *** join/#card10badge sur5r (~sur5r@x3650.sur5r.net) |
| 03:30.20 | *** join/#card10badge leibert (sid26580@gateway/web/irccloud.com/x-tzsllvxvzjvkmmjk) |
| 03:55.21 | *** join/#card10badge jrt (~jrt@dynamic-077-013-180-146.77.13.pool.telefonica.de) |
| 04:02.06 | *** join/#card10badge erlehmann_ (~erlehmann@dynamic-046-114-038-120.46.114.pool.telefonica.de) |
| 05:34.56 | *** join/#card10badge DocScrutinizer05 (~saturn@openmoko/engineers/joerg) |
| 07:09.15 | *** join/#card10badge jobroe (~manjaro-u@p57a59eb7.dip0.t-ipconnect.de) |
| 08:15.56 | *** join/#card10badge theAntimon (~matze@p5b313488.dip0.t-ipconnect.de) |
| 08:16.27 | *** part/#card10badge theAntimon (~matze@p5b313488.dip0.t-ipconnect.de) |
| 08:55.45 | *** join/#card10badge msvb-lab (~msvb-lab@monero/hardware/michael) |
| 10:21.38 | *** join/#card10badge mmu_man (~revol@82-65-227-82.subs.proxad.net) |
| 10:37.41 | *** join/#card10badge theAntimon (~matze@wf0277.dip.tu-dresden.de) |
| 10:40.33 | *** part/#card10badge theAntimon (~matze@wf0277.dip.tu-dresden.de) |
| 11:12.57 | *** join/#card10badge mmu_man (~revol@82-65-227-82.subs.proxad.net) |
| 11:42.37 | schneider | it takes about 160 ms to load a 160x80 RGB png from flash, decode it and display it |
| 11:43.48 | schneider | 45 to load it, 75 to decode it, 40 to display it (blit+update) |
| 11:45.40 | schneider | png is about 16kb large |
| 13:18.41 | *** join/#card10badge theAntimon (~matze@wf0277.dip.tu-dresden.de) |
| 13:20.52 | *** part/#card10badge theAntimon (~matze@wf0277.dip.tu-dresden.de) |
| 13:43.50 | *** join/#card10badge DocScrutinizer05 (~saturn@openmoko/engineers/joerg) |
| 13:49.03 | *** join/#card10badge erlehmann (~erlehmann@dynamic-046-114-038-120.46.114.pool.telefonica.de) |
| 14:26.39 | *** join/#card10badge erlehmann (~erlehmann@dynamic-046-114-032-081.46.114.pool.telefonica.de) |
| 14:34.42 | *** join/#card10badge erlehmann (~erlehmann@dynamic-046-114-032-081.46.114.pool.telefonica.de) |
| 18:05.48 | *** join/#card10badge erlehmann (~erlehmann@dynamic-046-114-032-081.46.114.pool.telefonica.de) |
| 19:55.17 | *** join/#card10badge msvb-lab (~msvb-lab@monero/hardware/michael) |
| 19:58.47 | *** join/#card10badge erlehmann (~erlehmann@dynamic-046-114-032-119.46.114.pool.telefonica.de) |
| 22:28.53 | *** join/#card10badge theAntimon (~matze@p5b31314b.dip0.t-ipconnect.de) |
| 22:29.02 | *** part/#card10badge theAntimon (~matze@p5b31314b.dip0.t-ipconnect.de) |
| 22:29.06 | schneider | Rahix: pippin: https://git.card10.badge.events.ccc.de/card10/firmware/-/merge_requests/457 |
| 22:29.11 | schneider | what do you thing about that? |
| 22:29.27 | schneider | i suggest do modify blit() to be able to direclty work with RGBA data |
| 22:30.33 | pippin | schneider: the texturing functions in ctx support RGBA8 BGRA8 and RGB565 .. no 565A though |
| 22:32.09 | pippin | 565A would perhaps rather be 5,5,5,1 for R,G,B,A ... that sometimes occurs, RGB565 + a 1bit alpha bitplane following would be rather uncommon |
| 22:53.09 | schneider | i see |
| 22:57.55 | schneider | pippin: oh, wow that stb_image library supports _a lot_ of formats |
| 22:57.57 | schneider | hm... |
| 23:03.27 | pippin | IIRC jpg+png+gif in one l0dable as a generic good image|slideshow viewer but became too much in a single l0dable |
| 23:05.11 | pippin | my next big todo-item in ctx is making images work for the protocol, in both text and binary form |
| 23:09.41 | pippin | if there is enough RAM for some textures on core 0 - then it could even be possible to make a copy of an encoded image file to the commandbuffer, which if we continue with synchronous instead of ascynchronous render - would stay as valid data as core0 is running the rasterizer, which would decode the png/jpg on demand to one of a set of named texture slots. |
| 23:19.05 | pippin | the protocol will initially not include PNG|JPG|GIF etc, but start of with RGBA8 / BGRA8 / RGB565 / RGB332 binary blobs. The blobs *could* be referenced directly if constraints are placed on the drawing commands of ctx, but being able to reuse some textures by name is more important for the API |
| 23:21.54 | *** join/#card10badge erlehmann (~erlehmann@dynamic-046-114-034-101.46.114.pool.telefonica.de) |
| 23:25.45 | pippin | schneider: is there much RAM to use for a fixed pool of texture data? |
| 23:25.57 | schneider | pippin: i can't say at the moment |
| 23:26.44 | schneider | i'd need to ask the heap of a running system ;) |
| 23:28.08 | schneider | but what i got from your line above is that i should probably focus on rgb8, rgba8 and rgb565 |
| 23:28.19 | pippin | the model I am going for when using textures interactively over serial links on desktop is that textures used in the previous frame, or earlier in current frame are expected to be available for reuse directly by "key" rather than value |
| 23:28.31 | schneider | i just want to put something together quickly which solves my current need |
| 23:29.33 | schneider | pippin: yeah |
| 23:29.37 | pippin | this caching strategy translates to an expectation that can be reasoned with easily in each client, and any stronger guarantee of life-time is easy to achieve intially. |
| 23:29.46 | schneider | i mean in the end it is a question the user has to answer |
| 23:30.10 | schneider | if they try to put 200 kb of textures into core 0, something will abort |
| 23:30.48 | pippin | and for a fixed-arena embedded case - when running out of texture memory, not being able to meet the constraint - start scaling down and dropping bits - getting glitchy but perhaps surivable results |
| 23:31.51 | schneider | the thing is that i currently have not good idea how much ram a busy system is actually using |
| 23:32.54 | schneider | (i'm not even sure how much dynamic memory is uses apart from the stacks for the threads) |
| 23:35.03 | pippin | perhaps try making a 128kb allocation that you do not use, and see if that upsets anything |
| 23:36.44 | schneider | i had a quick look and i think only the l0der and the file system allocate anything |
| 23:39.17 | schneider | ah, the max86150 and max30001 might allocate queues |
| 23:39.47 | schneider | bhi as well |
| 23:39.56 | schneider | but that should be in the single kb region |
| 23:42.21 | schneider | stacks seem to be 49 kb and data+bss is 135 kb |
| 23:42.48 | schneider | that leaves about 70 kb free |
| 23:44.35 | pippin | the ctx rasterizer itself takes ~6kb of RAM, bringing us down to 64kb |
| 23:45.46 | pippin | which still is more than two screenfuls in 565 - and for lighter uses some quite fun fast sprite-things with RGBA8 sprites possible |
| 23:47.00 | schneider | so a friend of mine had the idea to create a tamagotchi for the card10 for next camp |
| 23:47.35 | schneider | and i'm all for it. I'm thinking about a little rocket that you have to keep happy |
| 23:48.15 | schneider | so, yeah :) |
| 23:51.50 | pippin | keeping the binary variant of the ctx protocol used on the card10 means a lot less testing, and I do think ~64kb is doable |
| 23:53.04 | pippin | the ~64kb could even be used for a run-time optional (controlled by ctx on core0 itselg depending on textures in use) text rendering cache |