On 07/15/15 14:35, Hans Verkuil wrote: > On 07/14/15 12:16, Daniel Vetter wrote: > > <cut away old quotes> > >>>>> I would guess that a LUT supporting 16 bit color components would need a precision >>>>> of 0.20 or so (assuming the resulting values are used in further calculations). >>>>> >>>>> High dynamic range video will be an important driving force towards higher bit depths >>>>> and accurate color handling, so you can expect to see this become much more important >>>>> in the coming years. >>>>> >>>>> And as I mentioned another consideration is that this fixed point data type might >>>>> be useful elsewhere in the kernel where you need to do some precision arithmetic. >>>>> So using a standard type that anyone can use with functions in lib/ to do basic >>>>> operations can be very useful indeed beyond just DRM and V4L2. >>>> >>>> 0.20 would still comfortably fit into 8.24. And yeah worst-case (in 10 >>>> years or so) we need to add a high-bpp variant if it really comes to it. >>> >>> I think this is much closer than you think. I agree that you are not likely to see >>> this soon for consumer graphics cards, but for professional equipment and high-end >>> consumer electronics this is another story. >>> >>> And if it is being done for input, then output will need it as well: after all, >>> what's the point of 16-bit color components if you can't display it? Whether Intel >>> will support it is another matter, but there are other vendors, you know... :-) >> >> Input is different because of post-processing - you need that much depth >> to be able to get useful data out of the dark areas, without the risk for >> the highlights to clip. While processing you need that depth to avoid >> banding (because integer math sucks). But tbh I haven't seen anything but >> 12bpc (and those usually use dithered 10bpc panels internally) anywhere >> and the common screens top out at 10bpc. >> >> So from my pov of drm s8.24 will be enough for a long time, but if you're >> convinced that the input side needs this soon I guess it makes sense to go >> with the bit more overhead and 32.32. Otoh we'll never need 32 of integer >> part if we normalize to 0.0-1.0, and that normalization is really >> something I think we want. > > I think 32.32 is primarily important as a standard data type for public APIs > and as the standard data type for math operations. How it is stored in the > driver is driver (or possibly subsystem) specific. Is it a problem for you to > store it as 8.24 in the driver (specifically for LUTs) to reduce memory usage? > Converting from 8.24 to 32.32 and vice versa is trivial, so this might be the > best of both worlds. Follow-up: I just read through the latest Color Manager Implementation patch series and there the LUTs use U8.24 and CSC use S31.32. Since DRM will always use LUT values in the range [0-1] and given the fact that these values are just stored and not used in further calculations, I think that this is OK. V4L2 might still use 32.32 for a LUT (currently we don't support that yet, but we likely will in the near future), but that's OK. As long as any fixed point math functions we create in the kernel all use S31.32 so they can be shared between DRM and V4L2 (and quite possibly other subsystems) I have no problems with this scheme. Regards, Hans _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
