On Wed, 2017-07-19 at 10:15 +0100, Ian Arkver wrote: > On 19/07/17 09:09, Philipp Zabel wrote: > > Hi Ian, > > > > On Wed, 2017-07-19 at 08:16 +0100, Ian Arkver wrote: > >> Hi Philipp, > >> > >> On 02/03/17 10:19, Philipp Zabel wrote: > >>> Side effects are reduced burst lengths when writing out decoded frames > >>> to memory, so there is an "enable_bwb" module parameter to turn it back > >>> on. > >> > >> These side effects are dramatically reducing the VPU throughput during > >> H.264 encode as well. Prior to this patch I was just about managing to > >> capture and stream 1080p25 H.264. After this change it fell to about > >> 19fps. Reverting this patch (or presumably using the module param) > >> restores the frame rate. > >> > >> Can we at least make this decode specific? The VPU library patches do it > >> in vpu_DecOpen. I'd guess disabling the BWB any time prior to stream > >> start would be OK. > > > > Yes, since ENGR00293425 only talks about decoders, and I haven't seen > > any BWB related hangups during encoding yet, I'm inclined to agree. > > I took a look at where ctx->frame_mem_ctrl is used, i.e. > coda_start_encoding and __coda_start_decoding. Is it possible to have > one instance of coda open for encode and one for decode at the same > time? Sure, when transcoding with a decoder / encoder pair, for example. > If so, how is the CODA_REG_BIT_FRAME_MEM_CTRL setting > updated between runs, eg. for differing CODA_FRAME_CHROMA_INTERLEAVE? Yes. coda_command_async writes ctx->frame_mem_ctrl to CODA_REG_BIT_FRAME_MEM_CTRL with each PIC_RUN command at from prepare_encode/decode. > This code is in the start_streaming path rather than the prepare_run > path. Does each context switch stop & restart streaming? No, see above. regards Philipp
