On 11/22/2013 01:16 AM, Kristian Høgsberg wrote: > I'm not sold on the nested compositor for this use case. It > introduces another context switch between the game and the main > compositor and more input and output lag. Instead I think we need to > consider whether we want a new __DRIimage entry point like: > > (*blitImage)(__DRIcontext *ctx, __DRIimage *src, __DRIimage *ctx) > > and then do the copy in platform_wayland.c when we have non-matching > tile-formats. > > Kristian >
Thanks for the comments. There are advantages to both possibilities: using a nested compositor or doing the copy inside Mesa. I imagine doing a blit could be the default, and rendering directly to the linear buffer could be an option set by an env var, or driconf. I'm deeply convinced we should allow to render to the linear buffer without copy, and the nested compositor use-case makes sense. For the blit, a function (*blitImage)(__DRIcontext *ctx, __DRIimage *src, __DRIimage *dst) makes sense, but we would need another function (not related specifically to Prime): (*throttle) (__DRIcontext *ctx) Because rendering something heavy on non-intel card (intel cards to throttling automatically) cause input lag (and It is solved by forcing throttling at every swap). And ideally, we could have more control on tiling, for example if the computer has two AMD cards of the same generation with same tiling modes, we could always use tiling. >I would like the compositor to still send the classic drm device in >the wl_drm.device event. The client can then use stat(2) to stat it >and defer the corresponding render node from that by adding 128 to the >minor. This way we don't break older mesa versions by sending them a >render node that they'll then fail to authenticate. I do not agree on this: if the compositor does run under a render-node, there are high chances it can't authenticate clients wanting to run on the not-render-node device. Moreover, I believe clients shouldn't use render-nodes by default if they can avoid it. I don't get the point of older mesa versions: why would you use an older Mesa version inside a more recent Mesa version? Some arguments in favor of allowing the nested compositor case to render without copy on another card: . XWayland inside would run as if the main device is the device of the nested compositor. (I can't say how X dri3 will support Prime, so I can't say yet if this is a big advantage or not). For example if Xrender is slow on the main card, you can with this system use Xrender on the other card. . In case you are under system compositors (like would KWin), you would like to be able to render your whole desktop on the card you want, without an additional copy. . We could imagine having outputs on different card, the compositor under system compositors would connect to multiple system compositors running on each card (and giving access to different outputs). The compositor would use card X: the system compositor on card X would have tiled buffers without copies, whereas the other system compositors would have untiled buffers without copies. . The nested compositor could allow the user to choose between capping the compositing to 60 fps or not. When we would cap the compositing to 60 fps, we would avoid some useless copies (while adding a very small latency between when the frame is sent and when it is displayed) (. The nested compositor could have additional features like recording using the acceleration of the other card ) All these arguments can be put in short in: "more flexibility" For an heavy game < 60 fps, I agree it makes much more sense to do the copy inside Mesa, than using a nested compositor. Axel Davy _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
