Mode manager / Framebuffer management (WAS: Re: [Dri-devel] Memory management of AGP and VRAM)

[David Bronaugh]

Mike Mestnik wrote:
Let me start of by saying I think you are on the right track and all of
your ideas look good.
--- David Bronaugh <[EMAIL PROTECTED]> wrote:
 

Mike Mestnik wrote:
   

This is vary good.
- To accomidate mergedfb the number of FBs should be allowed to be 0.
     

How does mergedfb work internally? I don't know.
   

However we need it to?  I think if we cripple X the current mergedfb will
also have to be crippled.
 

I think this design allows for mergedfb to work "however we need it to" 
by encapsulating all that (setup) logic within the "Extended DRM" module.

Do you disagree?
Alternatively to this, maybe the best way to do this would be to specify
a double-width mode (eg 2048x768) and an extra "feature" parameter of 
MERGEDFB or some such -- that might work. However, I can't claim to 
understand mergedfb (as in, how it's implemented) yet, so this is 
probably a naive solution.

   

I see it more as just a way of pointing a viewport to a framebuffer, like
a screen(FB) swap.  What I see is that a FB gets allocated and then modes
get set, with it's viewport looking into this FB.  This can all be part of
the modesetting code, then the FB and the viewport should be returned. 
That way the FB can be deallocated, after a succsesfull FB change.  There
will be rare cases where the card can't handel both FBs then the FB
allocate code might need to handel this NEEDED deallocate/change inorder
to allocate the new/replacing FB.
 

Hmm, I don't really see any disagreement here. In fact, I think you're 
filling in useful missing details in my understanding.

The framebuffer alloc code will be part of the proposed "Extended DRM" 
infrastructure -- which I would rather not be part of (beyond what I 
want to do).

Hopefully modes can be set withought FBs this cuts down on the FB
{a,de}lloc code.  However inorder to cutdown on card specific code, it may
be best for all cards the deal with worst-case FB alloc, if this is to be
a feature.
 

All allocation of framebuffers will happen within the kernel. None will 
be requested by the mode manager.

- Sharing of FBs should be allowed, for heads on the same card.
     

Same deal, except instead of a "feature" of MERGEDFB, the "feature" 
should be CLONE

   

I don't like the idea of having things so static.  Attaching and
deattaching modes(viewports) from FBs should be done via a full API.  If
this is at all possible?
 


I don't know whether it is or not. I kind of like this kind of 
simplicity, though -- I think it allows for simply adding numbers if 
needed, which would be

- There is no way to ?change?(read as specify) the size of a FB.
     

If you can specify the resolution, you can specify the size of the 
framebuffer. What else did you have in mind?

   

Size of viewport != FB size, thought I think you got that by the end of my
msg.
 

Yeah, I understood that.
- Allocating the second/... FB may be difficult,
     

My comments above and below, as two diffrent cases.
 

Shouldn't be a problem.
 - Have mem free as well as mem total.
     

This helps with multi-tasking, I.E. Two apps sharing the same VT(context).
For multi-headed cards thay will have to share FB resources.
 

- Returning hardware capabilitys(like in a termcap type way), not
     

just
   

mem sizes.  I.E. zbuffer type(how to know it's size).
     

Allocating a FB on some cards may not be a simple as L*H*D.  As I'm not an
expert on hardware I don't know what snags you might hit on, that are not
version but card dependant.
 


     

Hmm... I'd love for you to elaborate here, though I -think-  I know what
you're getting at.
   

I wish I could but I realy don't know, it's just something I think the
desing might need. I used the source and saw into the future.
 

OK; elaborate?
Virtual fb vs Actual FB.  IMHO Actual FB is the monitors mode and not the
allocated size of the FB(Virtual fb).
 

That's the idea.
This is what the mode manager receives:
struct ms_mode {
   __u32 xres;
   __u32 yres;
   __u32 bpp;
   __u32 refresh;
};
   

No FB?  This may be positive.
 

I -did- forget to specify the PCI dev, and the CRTC number (screen 
number, whatever). That should be added to the struct -- maybe something 
like this:

struct ms_mode {
   char * pci_dev;
   __u32 crtc_no;  
    __u32 yres;
    __u32 bpp;
    __u32 refresh;
};

I can't think of any cases where you'd actually -need- to call the video 
BIOS in order to change the framebuffer pointer or offsets (if this were 
true, GL would be a nightmare on those cards).

Please. I need more feedback here, people. SPEAK! Destroy my ideas! 
Nitpick until this proposal looks like swiss chese! The more feedback 
there is, the better it will be.

David Bronaugh
-------------------------------------------------------
This SF.Net email is sponsored by: SourceForge.net Broadband
Sign-up now for SourceForge Broadband and get the fastest
6.0/768 connection for only $19.95/mo for the first 3 months!
http://ads.osdn.com/?ad_id=2562&alloc_id=6184&op=click
--
_______________________________________________
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel