14:52 tomeu: EMIT(REG_CNA_S_POINTER, CNA_S_POINTER_POINTER_PP_EN |
14:52 tomeu: CNA_S_POINTER_EXECUTER_PP_EN |
14:52 tomeu: CNA_S_POINTER_POINTER_PP_MODE(1));
14:52 tomeu: phh: does that look ergonomic enough?
14:54 phh: uh, I don't recognize what this instruction is supposed to mean, i'll need the documentation, give me a bit of time
14:55 tomeu: it's just the first one in your demo
14:56 tomeu: I'm just playing with different ways of expressing the TRM in xml, and generating code
14:56 tomeu: as doing that by hand is error-prone and a PITA
14:57 phh: uh yeah just to clarify, the hexa values I have in my demos are from a dump of the commands from proprietary stack, I didn't write them all by hand
14:57 tomeu: yes, I meant if we were to write by hand the defines, etc
14:57 phh: but yeah I agree
14:57 phh: anyway that's the way it's usually done in mesa afaik?
14:58 tomeu: from the TRM
14:58 tomeu: there are several ways of doing it
14:58 tomeu: panfrost used to be done by hand, before Arm gave docs
14:58 tomeu: looks like envytools is the most appropriate here, as used as well in freedreno and etnaviv
14:59 phh: yeah okay, I didn't understand your extract because I expected s_pointer register to be... a pointer
14:59 phh: so yeah looks sane to me
15:00 phh: I do wonder whether you could reduce to EMIT(REG_CNA_S_POINTER, POINTER_PP_EN | EXECUTER_PP_EN | POINTER_PP_MODE(1)) by concatenating the name of the register
15:01 tomeu: yeah, guess that if there was a clash, we would notice via a build failure, at least
15:05 phh: that's not what I meant
15:05 phh: uh wait, I don't know how much recursive can macros be
15:05 phh: can you do EMIT(x,y,z) that uses macro x_y ?
15:05 tomeu: ah, I think I see what you meant
15:05 phh: hum no there is no need for that, REG_CNA_S_POINTER_POINTER_PP_EN doesn't have to be a macro, it can be a const
15:06 phh: but then you need to trust the compiler to inline it
15:06 tomeu: I would prefer to avoid too much magic, TBH
15:06 phh: yeah right I agree, that's too much complexity for not a great improvement
15:35 tomeu: phh: do you happen to have handy a binary dump of a regcmd buffer?
15:39 phh: I'm checking. That being said, I can't even find the code I used to dump those registers
15:39 phh: ah found it
15:42 phh: tomeu: https://github.com/phhusson/rknpu-reverse-engineering/tree/main/mess hello.c is how I dumped them, and you have various dump. You can ignore the "paddr xxxxx" thingies since they are obviously wrong once you read the TRM rather than guessing
15:43 tomeu: that's great, thanks!
15:46 tomeu: phh: actually, just realized that those files are text, I would need a binary dump to test the decoder
15:47 phh: ah ok understood
15:47 phh: I don't have that then, sorry
15:47 tomeu: ok, no
15:47 tomeu: I also lost mine for some reason
15:47 phh: I have touched my rk3588 in a while. If I'm motivated to boot it again I'll try thinking of it
15:49 phh: do you have ideas of what kind of models you'd want to try? IIRC I started with a single layer of convolution + ReLU, and tried 84x84 and 85x85 matrices to understand how it was handling the limits
15:49 tomeu: np, I still need to get my RE scripts up and running