Hi Lynne, Thanks for your thoughts. My thoughts I have embedded below
On Mon, Jun 29, 2020 at 6:32 PM Lynne <d...@lynne.ee> wrote: > Jun 28, 2020, 22:40 by hanish...@gmail.com: > > > Hi Mark, > > > > **** hwdownload vs separate filter > > > > True, for kmsgrab use-case one could potentially do this transform as > part > > of the drm_transfer_data logic (which currently mmaps and does a linear > > copy, if even I remember correctly). But like what I had mentioned in my > > previous email, as this is done on the cpu side, if one wants to capture > > very large framebuffers (say 4K or 8K at high fps), it could impact the > > performance to some extent, so in such a situation decoupling the capture > > from detiling, allows one to capture the screen at a very high resolution > > without worrying about detiling and then handle detile in a offline / > > separate pass manner. > > > > I too think the filter must be done during hwdownload. That's the only > place > where it fits, since the tiling is known, and also the intent to access > the buffer > is known. > We should not be outputting raw, tiled data in the first place and if speed > really is necessary the detiling can be SIMD'd to speed it up > significantly. > > Do note that if one uses kmsgrab currently it will be outputting raw tiled data only, if the underlying framebuffer is tiled. So it is not a new behaviour, but what exists currently. And as I had mentioned before, if we embed this logic into hwdownload, then it can be used only when capturing using hardware context, while by keeping the logic as a separate filter, the end user has the flexibility to use it as they may find suitable for their situation. Also the overhead added by the separate filter to the path is minimal. Isn't the whole idea of unix kiss principle and piping as well as filter chaining in the first place to have each logically independent | self contained functionality as its own and give the user the freedom to mix and match things the way they want for their end use. And this definitely follows that. > > > NOTE1: Also as a side note, I dont think the existing logic is currently > > fetching the format modifier of the actual frame buffer, I think it gets > > set to NONE type by default and remains like that, unless user passes the > > format_modifier argument, but I could be wrong in this understanding of > > mine, as I have only gone through the code flow quickly once and also as > I > > am in alien territory in some sense at one level. > > > > kmsgrab might not, but other APIs certainly do. > Also, we don't top post on this mailing list. > _______________________________________________ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > To unsubscribe, visit link above, or email > ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". -- Keep ;-) HanishKVC _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
