Created attachment 354862 [details] [review]
glupload: Put directviv upload high priority than dma upload

Why? If both are available and can be used, it shouldn't really make a difference?

(In reply to Sebastian Dröge (slomo) from comment #2)
> Why? If both are available and can be used, it shouldn't really make a
> difference?

Yes, both are supported on i.MX8 platform. We add memory copy in dma upload to support none dma case on other platform. The new vpu on imx8 only can output physical memory buffer， then it will go through the dma memory copy and performance is bad. Actually, it can go through directviv with zero-copy.

That dmabuf is implemented less efficient than directviv sounds weird. Can't both go through exactly the same code paths internally, and basically have the dmabuf carry the same information as the physical memory buffers?

(In reply to Sebastian Dröge (slomo) from comment #4)
> That dmabuf is implemented less efficient than directviv sounds weird. Can't
> both go through exactly the same code paths internally, and basically have
> the dmabuf carry the same information as the physical memory buffers?

On early imx8DV platform， there is no VPU（video process unit）and software decode can only output system memory buffer. But it realy has an dmabuf allocator called ion. To avoid glupload go through raw data upload, we did a memory copy in dmabuf upload and copy system memory to a new allocator dmabuf then pass it to GPU. 

It also works on imx6 because imx6 has no ion and will fail at allocator dmabuf. Then it will fallback to directviv.

All imx platform share the same code and the recent imx8 platform has implement VPU to do video decode and support physical memory buffer but it also has ion dmabuf allocator. Then it will go through dmabuf upload. This is not right. Actually we need check if the buffer is physical memory buffer first and then dmabuf.

(In reply to Haihua Hu from comment #5)
> All imx platform share the same code and the recent imx8 platform has
> implement VPU to do video decode and support physical memory buffer but it
> also has ion dmabuf allocator. Then it will go through dmabuf upload. This
> is not right. Actually we need check if the buffer is physical memory buffer
> first and then dmabuf.

This of course is not normally something userspace shall be aware of, this is special hack form Freescale/NXP/Qualcomm (not sure which name you use now ;-P).

Though, if your decoder produces DMABuf allocated using the CMA, you should not need your "physical memory" hack anymore. The reason the current uploader is slower is most likely because it's doing the color conversion on the GPU (R8 + RG88 + shaders), which I believe is still pretty slow even on newer IMX.

For Etnaviv, which does not implement your "physical memory" hack, they started adding a direct upload to glupload. In Etnaviv, the VPU is used instead for conversion. The result has been reported has good as the other method, with the benifit it's standard and can be used on other boards. Patches are over there:

  https://bugzilla.gnome.org/show_bug.cgi?id=783521

Meanwhile, I'm just encouraging you to move forward something slightly more standard, I don't see any problem of moving this uploader higher in the stack, after all this is only used on your platform, actually it's only used with your SW stack.

This is probably not something we're going to do.  Working with the direct dma-buf uploader is the best way forward for this.