On Mon, May 07, 2012 at 01:57:37PM +0200, Gerd Hoffmann wrote: > On 05/07/12 12:28, Alon Levy wrote: > > On Mon, May 07, 2012 at 12:01:42PM +0200, Gerd Hoffmann wrote: > >> Hi, > >> > >>> But there is no concept of an additional surface in the guest driver. > >>> RANDR 1.2 (and I think the same for 1.3, 1.4, since we don't have per > >>> CRTC pixmaps) has a single screen wide pixmap. A screen is one per X > >>> server, so there is just one even if you have multiple heads. And the > >>> CRTCs scan out of it. To copy the RANDR docs diagram (removed the double > >>> output): > >>> > >>> > >>> ┌─────────────────────────────────┐ > >>> ┏━━━━━━━┳───────────────┐ ╔════════╗ > >>> ┃ 1 ┃ │ ║ A ║ > >>> ┃ ┏━━━╋━━━━━━━━━━━━━━━┫ ║ ║ > >>> ┣━━━╋━━━┛ ┃ ╚════════╝ > >>> │ ┃ 2 ┃─────────────────┐ > >>> │ ┃ ┃ ╔═══════════════════╗ > >>> │ ┃ ┃ ║ ║ > >>> │ ┗━━━━━━━━━━━━━━━━━━━┫ ║ B ║ > >>> └───────────────────────┘ ║ ║ > >>> ┌──────┐ ┏━━━━┓ ╔══════╗ ║ ║ > >>> │screen│ ┃CRTC┃ ║output║ ╚═══════════════════╝ > >>> └──────┘ ┗━━━━┛ ╚══════╝ > >>> > >>> So if we were to create an additional surface we will have to issue copy > >>> commands for it from the primary surface. > >> > >> I don't think you have to copy. You have both width and stride fields > >> for surfaces. stride doesn't need to be width * depth, you can add > >> padding. Which allows you to allocate a large pixmap in device memory, > >> then create multiple surfaces which each representing parts of your > >> large pixmap. > > > > OK, sorry, this was exactly what I had in mind for the client side > > implementation of QXLHead, so I should have thought of it for the > > additional surfaces as well. > > > >> > >> The approach still has its drawbacks: Rendering ops need some extra > >> math, and you can't submit rendering ops for invisible regions of your > >> large pixmap. The biggest issue are overlapping crts I suspect. They > >> would lead to overlapping surfaces. Ouch. > > > > I don't follow. Your suggestion if I understand is to have a new surface > > generated by the driver that uses the same image with different stride, > > width, and starting location (allowing it to be a rect within the > > primary surfaces) compared to the primary surfaces. > > No. The big rectangle in the picture above (the large pixmap) has no > surface associated with it at all. The small "1" rectangle is the > primary surface, rectangle "2" is the secondary head surface. > > No need to copy. But as mentioned the intersection is part of two > surfaces now, which I'd expect to cause problems, and anything outside > the "1" and "2" rectangles has no surface associated with it and thus > can not be src or dst of rendering ops. The thing is that you would still have copies, you just moved them to the driver - since by definition the big rectangle, the screen, is covered by the screen's pixmap, there would still be a pixmap. Maybe you could make it so it isn't ever actually used, maybe you can even make it zero sized, I don't know, but it's not the way it is supposed to work. > > Just defining heads as a viewport to the primary surface (maybe allow > any surface here?) should work fine. OK, I'll go down this path then. > > cheers, > Gerd > _______________________________________________ > Spice-devel mailing list > Spice-devel@xxxxxxxxxxxxxxxxxxxxx > http://lists.freedesktop.org/mailman/listinfo/spice-devel _______________________________________________ Spice-devel mailing list Spice-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/spice-devel