[Spice-devel] multiple heads memory arrangement

[Noel Van Hook]

On Wed, Apr 18, 2012 at 11:12 PM, Alon Levy <alevy at redhat.com> wrote:
>
> On Wed, Apr 18, 2012 at 03:56:54PM -0600, Noel Van Hook wrote:
> > I am not sure I fully understand the ramifications of having a list of ram
> > headers.  Is the intent to have one additional ram header per additional
> > head?
>
> Yes, that was the idea.
>
> >
> > For multiple heads to work correctly, I believe:
> > 1) the framebuffer must be contiguous
> > 2) the entire framebuffer must be accessible to all heads, and
> > 3) each head must be able to be abitrarily located in that framebuffer.
>
> Do you have any pointers to these? About #3 I understand, but I wasn't
> aware of #1 or #2.


XRandR will use xf86CrtcFuncsRec.mode_set to set the video mode for
each head.

Parameters to this function identify the mode to be set (thereby
defining the width and height of the head), and the x,y point which
identifies the upper left corner of this head within the framebuffer.

It is these (x,y) parameters the determine the overall layout of the
heads.  So if all heads get an origin of (0,0) you get clone mode.
If you set up two 1024x768 heads side-by-side, one gets an origin of
(0,0) an done gets an origin of (1024,0).

As a result of this, rectangle coordinates provided to
qxl_surface_copy will be relative to the framebuffer, not any head.
(This provides the chief benefit to multi-head, which is that moving
data between heads becomes a simple blit within the framebuffer
surface).

Another benefit is that if the heads are set up in clone mode (all
their origins are 0,0), X will draw to the framebuffer only once,
and expect the results to appear correctly on all heads, rather than
having to draw the same thing multiple times.

In order for all this to work correctly, I believe the entire
framebuffer must be a contiguous surface, and each head must be able
to be arbitrarily placed anywhere in that surface.


Noel.

>
> But that said the framebuffer creation is already pretty
> flexible with QXL. The guest issues a CreatePrimary IO and fills in the
> header's (the specific head's one, actually this brings a good point -
> it has to use different io ports - I guess I'll need to add a rom field
> for that) create_primary field, which has a QXLPHYSICAL address of the
> surface start, and a stride != width * bpp neccessarily. So it can
> certainly have a single on pci framebuffer that overlaps all the heads
> if it wants to - it's a guest issue, spice will never acccess it
> directly but only via the primary surface for each head.
>
> >
> > Unless I misunderstand what you are doing, I am concerned that multiple ram
> > headers won't be flexible enough.
>
> I think the above description takes care of that.
>
> Thanks for the input,
> Alon
>
> >
> > Noel
> >
> >
> > On Wed, Apr 18, 2012 at 4:53 AM, Alon Levy <alevy at redhat.com> wrote:
> >
> > > Hi,
> > >
> > >  I'm just starting to work on this, wanted to solicit some feedback. I
> > >  am thinking that the simplest way to implement multiple heads would be:
> > >
> > >  Add additional QXLRam headers back to back on the vram bar.
> > >  Add a new flag QXL_RAM_FLAG_MORE_HEADS, set it on all but the last
> > >  (largest offset into bar) header.
> > >  Don't add new fields to QXLRom or QXLRam.
> > >  Update QXLRom.ram_header_offset to point to the first (smallest
> > >  offset) header.
> > >
> > > New driver that notices the QXL_RAM_FLAG_MORE_HEADS will count the
> > > headers (it cannot be done by looking at the header offset since it may
> > > not know about additional future data that will be put at the end of the
> > > bar).
> > >
> > > Old driver will lose sizeof(QXLRam) * (num_heads - 1) bytes from the end
> > > of the bar.
> > >
> > > Visually it would look like this for a two head qxl device:
> > >
> > >   .----------------------------------------------.
> > >   |                   ROM BAR                    |
> > >   | ...                                          |
> > >  || ram_header_offset                            |
> > >  || ...                                          |
> > >  ||                                              |
> > >  ||                                              |
> > >  |'----------------------------------------------'
> > >  |
> > >  |
> > >  |.--------------------------------------------------.
> > >  ||                     VRAM BAR                     |
> > >  |.--------------------------------------------------.
> > >  ||                   Working area                   |
> > >  ||                                                  |
> > >  v.--------------------------------------------------.
> > >   |                   First Header                   |
> > >   | magic                                            |
> > >   | ...                                              |
> > >   | flags == QXL_RAM_FLAG_MORE_HEADS                 |
> > >   |                                                  |
> > >   .--------------------------------------------------.
> > >   |                  Second Header                   |
> > >   | magic                                            |
> > >   | ... (identical fields) ...                       |
> > >   | flags == 0                                       |
> > >   '--------------------------------------------------'
> > >
> > > Alon
> > > _______________________________________________
> > > Spice-devel mailing list
> > > Spice-devel at lists.freedesktop.org
> > > http://lists.freedesktop.org/mailman/listinfo/spice-devel
> > >
> >
> >
> >
> > --
> > Noel Van Hook - Intelligraphics, Inc
> > 522 Cooper Ave N
> > Red Lodge, MT 59068
> > Noel.Van.Hook at Intelligraphics.com  (425) 770-5561
>



--
Noel Van Hook - Intelligraphics, Inc
522 Cooper Ave N
Red Lodge, MT 59068
Noel.Van.Hook at Intelligraphics.com  (425) 770-5561