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. > 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".
