search for: bsp_foo

...ine types > > enum nv84_decoder_eng_type > { > BSP = 0, > VP > }; > > #define NV84_DECODER_ENG_NUM VP + 1 Hmmm.... it's a point... the downside is that things become a little more confusing. I think there's some clarity to just having variable names like "bsp_foo" and "vp_foo" instead of "engines[VP].foo". And there are only 2 engines. One advantage of your approach is that it'd save on some initialization code. I dunno. If someone else likes this approach too, I'll try it out. > >> +struct nv84_decoder { >>...

...pe >> { >> BSP = 0, >> VP >> }; >> >> #define NV84_DECODER_ENG_NUM VP + 1 > > Hmmm.... it's a point... the downside is that things become a little > more confusing. I think there's some clarity to just having variable > names like "bsp_foo" and "vp_foo" instead of "engines[VP].foo". And > there are only 2 engines. When I came up with this I was looking at the nvc0 code, which was less intuitive struct nouveau_object *channel[3], *bsp, *vp, *ppp; struct nouveau_pushbuf *pushbuf[3]; > > One ad...

Adds H.264 and MPEG2 codec support via VP2, using firmware from the blob. Acceleration is supported at the bitstream level for H.264 and IDCT level for MPEG2. Known issues: - H.264 interlaced doesn't render properly - H.264 shows very occasional artifacts on a small fraction of videos - MPEG2 + VDPAU shows frequent but small artifacts, which aren't there when using XvMC on the same