On Fri, Nov 22, 2013 at 8:52 AM, Axel Davy <d...@clipper.ens.fr> wrote: > 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. >
We can actually use 1D tiling across all families since R600 IIRC since the tile size and alignment requirements are not asic dependent. Only 2D tiling as family dependencies. Alex > >>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 _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev