On Mon, 17 May 2004, Ville [iso-8859-1] Syrjälä wrote:
On Sun, May 16, 2004 at 08:08:10PM -0700, David Bronaugh wrote:
Vladimir Dergachev wrote:
This brings out an interesting memory management point: swappable versus
non-swappable graphics objects.
A framebuffer is obviously non-swappable, while
Ville Syrjälä wrote:
On Sun, May 16, 2004 at 08:08:10PM -0700, David Bronaugh wrote:
Vladimir Dergachev wrote:
This brings out an interesting memory management point: swappable versus
non-swappable graphics objects.
A framebuffer is obviously non-swappable, while textures are swappable.
N
The thing is most of these failure modes are software-based, not hardware.
The only real limitation is that the entire surface should be located
within *hardware* video RAM (which is limited to a single card, usually).
This brings out an interesting memory management point: swappable versus
non-
On Sun, May 16, 2004 at 08:08:10PM -0700, David Bronaugh wrote:
> Vladimir Dergachev wrote:
>
> This brings out an interesting memory management point: swappable versus
> non-swappable graphics objects.
>
> A framebuffer is obviously non-swappable, while textures are swappable.
Not just texture
Felix,
i have tried all tile formats. i get the same results using the 4 bit format
as i do with the 32 bit format. in both of these formats the colors are
correct but the image is warped. using the 16 bit format, the colors are
wrong and the image is warped. using the 8 bit format the colors are
Vladimir Dergachev wrote:
On Sun, 16 May 2004, David Bronaugh wrote:
Vladimir Dergachev wrote:
Yes, I think the mode/dac programing code should be seperat from the
frambuffer allocation/mngmnt code. Wather it should live in the
DRM is
another story, thought It should live kernel side as it workes
Mike Mestnik wrote:
--- David Bronaugh <[EMAIL PROTECTED]> wrote:
Mike Mestnik wrote:
--- David Bronaugh <[EMAIL PROTECTED]> wrote:
Mike Mestnik wrote:
--- David Bronaugh <[EMAIL PROTECTED]> wrote:
I think this design allows for mergedfb to work "however we ne
--- David Bronaugh <[EMAIL PROTECTED]> wrote:
> Mike Mestnik wrote:
>
> >--- David Bronaugh <[EMAIL PROTECTED]> wrote:
> >
> >
> >>Mike Mestnik wrote:
> >>
> >>
> >>>--- David Bronaugh <[EMAIL PROTECTED]> wrote:
> >>I think this design allows for mergedfb to work "however we need it
> to"
On Sun, 16 May 2004, David Bronaugh wrote:
Vladimir Dergachev wrote:
Yes, I think the mode/dac programing code should be seperat from the
frambuffer allocation/mngmnt code. Wather it should live in the DRM
is
another story, thought It should live kernel side as it workes closely
with the hardwar
Vladimir Dergachev wrote:
Yes, I think the mode/dac programing code should be seperat from the
frambuffer allocation/mngmnt code. Wather it should live in the DRM is
another story, thought It should live kernel side as it workes closely
with the hardware.
I don't think what I was proposing coupled
Yes, I think the mode/dac programing code should be seperat from the
frambuffer allocation/mngmnt code. Wather it should live in the DRM is
another story, thought It should live kernel side as it workes closely
with the hardware.
I don't think what I was proposing coupled or brought together the t
Mike Mestnik wrote:
--- David Bronaugh <[EMAIL PROTECTED]> wrote:
Mike Mestnik wrote:
--- 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.
On Sun, May 16, 2004 at 09:24:37AM -0700, Mike Mestnik wrote:
> Can 3D acceleration work in [1]ModeX? 2D?
>
> 1. Every n+1 pixel is for the next screen(FB). This format makes SW
> bliting of a pix to more than one screen faster, as you only have to
> iritate the source(and destination) once.
Mo
Can 3D acceleration work in [1]ModeX? 2D?
1. Every n+1 pixel is for the next screen(FB). This format makes SW
bliting of a pix to more than one screen faster, as you only have to
iritate the source(and destination) once.
--- Ville Syrjälä <[EMAIL PROTECTED]> wrote:
> On Sun, May 16, 2004 at 03:
On Sun, May 16, 2004 at 03:49:49AM -0700, Mike Mestnik wrote:
>
> A fue other questions, directed at the memory mngmt ppl. What about 2d
> only page fliping, ModeX and the like? Where these ever supported outside
> of libsvga? Are thay rellecs from the past that can die?
Page flipping is impor
--- David Bronaugh <[EMAIL PROTECTED]> wrote:
> Mike Mestnik wrote:
> >--- 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.
> >>>
> >>>
> >>>
>
16 matches
Mail list logo
