Hi Pekka, Thank you for the comments. I wIll start implementing the shader building.
Pekka Paalanen <[email protected]> writes: > On Wed, 23 Jan 2019 11:32:34 +0530 > Harish Krupo <[email protected]> wrote: > >> Hi, >> >> This is in continuation to the discussion in the mail chain here [1]. We >> are currently working on enabling HDR rendering support in the >> gl-renderer. HDR support requires color space conversion (709->2020 or >> other way around) and Tone Mapping, for which, we need to execute the >> following steps in the shader: >> * Degamma (to linearize the buffer) >> * Color space conversion (BT2020 -> BT709...) >> * Tone mapping (SDR -> HDR, HDR -> SDR, HDR -> HDR conversion) >> * Gamma: Apply gamma/transfer function for the display (PQ/HLG...) >> >> We are currently targeting the DCI-P3, SRGB and 2084 color spaces. One >> way to implement it would be to create multiple sets of shaders for each >> degamma/gamma combination. Like the one done by Ville in his POC [2]. >> This solution was a POC, and isn't scalable when we need to support >> multiple color spaces. I would like to propose 2 different solutions: >> >> Proposal 1: >> * Each of the shaders (gamma/degamma/main/tone mapping) would be >> independent strings. >> * When the view needs to be rendered, renderer will generate a set of >> requirements like need degamma PQ curve, need tone mapping, need gamma >> SRGB curve and so on. >> * These requirements (NEED_GAMMA_PQ...) would be bit fields and will be >> OR'd to create the total requirements. >> * This total requirement would be used to stitch the required shaders to >> compile a program. The total requirements integer will also be used as >> a key to store that program in a hashmap for re-use. >> >> Proposal 2: >> We could go for multi pass rendering, where each of the steps (gamma, >> csc, tone mappping, degamma) will be applied in different passes. Each >> pass would bind an fbo and call draw elements with the corresponding >> shader. This would not be as efficient but is another approach. >> >> Please comment on the approaches and do suggest if there is a better >> one. > > Hi Harish, > > choosing between multipass rendering and more complicated shader > building, I would definitely take the more complicated shader building > first. If the use case is video playback, then the clients will be > updating very often and the frames they produce will likely ever be > composited just once. Using multipass with intermediate buffers would > just blow up the memory bandwidth usage. > > Later, if someone wants to optimize things more for rarely updating > surfaces, they could implement an image cache for some stages of the > pixel conversions. > > Precision is another benefit of a complicated shader that does > everything in one go: the intermediate values in the shader can be > stored in GPU registers at high precision. Achieving the same precision > with multipass would cost a huge amount of memory. Memory saving is a > big reason why one almost always store images with gamma applied, even > in memory rather than just files. > > Btw. when enhancing the fragment shader mechanics, I think we could > rely more on the GLSL compilers than we do today. What I mean by that > is that we could have the shader's main call functions that do each of > the conversion steps to the pixel values, and then when concatenating > the shader string, we pick the appropriate function implementations into > it. No-op or pass-through functions ideally shouldn't produce any worse > code than manually not calling them. IOW, go with a more function than > macro oriented design in assembling the complete frament shader string. > > I think code maintainability and clarity should be the foremost goal, > but avoiding any serious performance issues. Fine-tuning the shader > performance, e.g. investigating a single "megashader" vs. multiple > specific shaders can be left out for now. Unless someone has solid > knowledge about what would be best already? > > Of course, we should stick to GL ES 2.0 capabilities if possible, but > we could also consider requiring GL ES 3.0 if that would seem too > useful to ignore. > > > Thanks, > pq > >> >> [1] >> https://lists.freedesktop.org/archives/wayland-devel/2019-January/039809.html >> >> [2] >> https://github.com/vsyrjala/weston/blob/hdr_poc/libweston/gl-renderer.c#L257 Regards Harish Krupo _______________________________________________ wayland-devel mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/wayland-devel
