page flipping
Ben Leslie
devices where double buffering (panning) isn't supported by the
underlying driver.
However, swapBuffers() doesn't actually seem to support PAGE_FLIP:
uint32_t EGLDisplaySurface::swapBuffers()
{
if (!(mFlags & PAGE_FLIP)) {
return 0;
}
....
}
If I add a memcpy() in there things seem to work correctly (at least
on the neo 1973).
Do I need to add this, or should non page flip work some other way?
Cheers,
Benno
Sean McNeil
> The current documentation implies that everything should work on
> devices where double buffering (panning) isn't supported by the
> underlying driver.
>
Page flipping is a little odd. It actually does a scroll which can be
very noticeable on some graphics chips. It can have severe performance
issues as well. I think it was also incomplete in that it swapped
between video memory and allocated memory when flipping isn't supported.
At times, the allocated memory appeared to not get updated. I haven't
looked to see if that was fixed.
If you disable flipping altogether and just set the 2 array values to
the same buffer, then it works just fine. There are some small issues
left, though, with the dialogs. Lots of repainting you can see when it
blurs the background and pops up the dialog.
Ben Leslie
>
> Ben Leslie wrote:
>> The current documentation implies that everything should work on
>> devices where double buffering (panning) isn't supported by the
>> underlying driver.
>>
>
> Page flipping is a little odd. It actually does a scroll which can be
> very noticeable on some graphics chips. It can have severe performance
> issues as well.
Yeah I noticed that. I'm not sure if Linux has a better way of
performing double buffering.
>I think it was also incomplete in that it swapped
> between video memory and allocated memory when flipping isn't supported.
That is what the set up code implies, but the page flip code is
stubbed out to return zero (as far as I can tell).
> At times, the allocated memory appeared to not get updated. I haven't
> looked to see if that was fixed.
>
> If you disable flipping altogether and just set the 2 array values to
> the same buffer, then it works just fine.
OK, that approach is possibly better doing the memcpy.
>There are some small issues
> left, though, with the dialogs. Lots of repainting you can see when it
> blurs the background and pops up the dialog.
That would be what I would expect.
I'll need to look at the 1973 hardware to see if there is a way of
implementing double buffering with hopefully just a register write.
(Or maybe I'll just get a freerunner and be done with it :)
Cheers,
Benno
Brian Swetland
> Ben Leslie wrote:
> > The current documentation implies that everything should work on
> > devices where double buffering (panning) isn't supported by the
> > underlying driver.
> >
>
> Page flipping is a little odd. It actually does a scroll which can be
> very noticeable on some graphics chips. It can have severe performance
> issues as well. I think it was also incomplete in that it swapped
> between video memory and allocated memory when flipping isn't supported.
> At times, the allocated memory appeared to not get updated. I haven't
> looked to see if that was fixed.
>
> If you disable flipping altogether and just set the 2 array values to
> the same buffer, then it works just fine. There are some small issues
> left, though, with the dialogs. Lots of repainting you can see when it
> blurs the background and pops up the dialog.
We haven't been doing any development on hardware without pageflipping
support. On the emulator and msm7k ports, the pan operation we use to
flip works well, but I think this is another area where we're going to
have to build some more flexibility into the system -- obviously what's
there now is not working everywhere and I suspect there may not be just
two options (flip/no-flip), but some variation in how flipping is handled.
Brian
Sean McNeil
One thing on my list that will significantly improve the user experience
with the Freerunner is to use some of its coprocessors. For instance, it
has an openGL capable graphics chip that would help. It also has an mp4
decoder that would smooth out the video quite nicely. Right now it is a
little blocky.
Not to mention it has Wifi. I forget if the gta01 has accelerometers,
but its nice to have video flip over when you turn the phones orientation.
> Cheers,
>
> Benno
>
> >
>
McHarg Chris
On 2008/11/02, at 14:01, Brian Swetland wrote:
> We haven't been doing any development on hardware without pageflipping
> support. On the emulator and msm7k ports, the pan operation we use to
> flip works well, but I think this is another area where we're going
> to
> have to build some more flexibility into the system -- obviously
> what's
> there now is not working everywhere and I suspect there may not be
> just
> two options (flip/no-flip), but some variation in how flipping is
> handled.
That reminds me... when looking at the i.MX31 fb flickering problem a
while ago, I noticed that android was using FBIOPUT_VSCREENINFO (which
calls fb_set_par etc along with fb_pan_display) instead of
FBIOPAN_DISPLAY to flip the display. Any ideas on the reason for doing
it that way?
Now that I have the code(!), it seems just swapping to FBIOPAN_DISPLAY
will work ok, so I might give that a try next week.
Matt Reimer
> I'll need to look at the 1973 hardware to see if there is a way of
> implementing double buffering with hopefully just a register write.
> (Or maybe I'll just get a freerunner and be done with it :)
If it's using the s3c24x0's lcd controller, you could do it by messing
with LCDBASEU/LCDBASEL in the LCDSADDR1/2 registers.
Matt
Mathias Agopian
On Nov 1, 11:41 pm, McHarg Chris <chris.mch...@gmail.com> wrote:
> Hi
>
> On 2008/11/02, at 14:01, Brian Swetland wrote:
>
> > We haven't been doing any development on hardware without pageflipping
> > support. On the emulator and msm7k ports, the pan operation we use to
> > flip works well, but I think this is another area where we're going
> > to
> > have to build some more flexibility into the system -- obviously
> > what's
> > there now is not working everywhere and I suspect there may not be
> > just
> > two options (flip/no-flip), but some variation in how flipping is
> > handled.
>
> That reminds me... when looking at the i.MX31 fb flickering problem a
> while ago, I noticed that android was using FBIOPUT_VSCREENINFO (which
> calls fb_set_par etc along with fb_pan_display) instead of
> FBIOPAN_DISPLAY to flip the display. Any ideas on the reason for doing
> it that way?
didn't support FBIOPAN_DISPLAY (and still don't). It looks like
FBIOPAN_DISPLAY is often not implemented in comparison to
FBIOPUT_VSCREENINFO.
Ideally the code there should try FBIOPAN_DISPLAY and if that doesn't
work, revert to FBIOPUT_VSCREENINFO.
> Now that I have the code(!), it seems just swapping to FBIOPAN_DISPLAY
> will work ok, so I might give that a try next week.
when FBIOPAN_DISPLAY is not supported.
> http://git.source.android.com/?p=platform/frameworks/base.git;a=blob;...
Mathias
Mathias Agopian
without page-flipping.
It is intended to work by performing a memcpy() as you have suggested.
We have actually fixed the non-page flipping case; but the code has
not been submitted yet.
Mathias
Mathias Agopian
On Nov 1, 8:47 pm, Sean McNeil <seanmcne...@gmail.com> wrote:
> Page flipping is a little odd. It actually does a scroll which can be
> very noticeable on some graphics chips.
performed synchronized with the refresh. Since it scrolls by a full
page, it is equivalent to swapping to another buffer. In which case
will it cause artifacts or be "noticeable"?
> It can have severe performance
impact?
> issues as well. I think it was also incomplete in that it swapped
> between video memory and allocated memory when flipping isn't supported.
> At times, the allocated memory appeared to not get updated. I haven't
> looked to see if that was fixed.
>
> If you disable flipping altogether and just set the 2 array values to
> the same buffer, then it works just fine.
acceptable for games or animations in the UI.
> There are some small issues
> left, though, with the dialogs. Lots of repainting you can see when it
> blurs the background and pops up the dialog.
not supported in hardware. The assumption here, is that hardware
manufacturers control their drivers and will implement the features
needed for proper graphics quality and performance.
Mathias
Sean McNeil
> Hello,
>
> On Nov 1, 8:47 pm, Sean McNeil <seanmcne...@gmail.com> wrote:
>
>> Page flipping is a little odd. It actually does a scroll which can be
>> very noticeable on some graphics chips.
>>
>
> Could you elaborate? The intention is that the scrolling is always
> performed synchronized with the refresh. Since it scrolls by a full
> page, it is equivalent to swapping to another buffer. In which case
> will it cause artifacts or be "noticeable"?
>
As far as I can tell, it isn't suppose to provide immediate refresh of
the screen, so there are graphics chips that smoothly move to the
alternate graphical area. On the Openmoko GTA01, you can see what looks
a little like a shift in the view and the top bar is ghosted near the
bottom of the display. On the Openmoko GTA02, it just runs exceedingly
slow. I'm not sure if it is the Glamo chip or the driver. I'll have to
check with my companion, but during early development we saw problems on
the TI OMAP2-Zoom reference flatform as well.
>
>> It can have severe performance
>>
>
> Can you precise in which scenarios it can have a severe performance
> impact?
>
On the GTA02, all graphics are slowed down significantly. The world time
zone, for instance, it is practically unbearable.
>
>> issues as well. I think it was also incomplete in that it swapped
>> between video memory and allocated memory when flipping isn't supported.
>> At times, the allocated memory appeared to not get updated. I haven't
>> looked to see if that was fixed.
>>
>> If you disable flipping altogether and just set the 2 array values to
>> the same buffer, then it works just fine.
>>
>
> This will cause flickering and tearing, unfortunately; which is not
> acceptable for games or animations in the UI.
>
Indeed. Also, as mentioned below dialogs don't work well either.
>
>> There are some small issues
>> left, though, with the dialogs. Lots of repainting you can see when it
>> blurs the background and pops up the dialog.
>>
>
> This is why a memcpy() is unfortunately, needed when page flipping is
> not supported in hardware. The assumption here, is that hardware
> manufacturers control their drivers and will implement the features
> needed for proper graphics quality and performance.
>
It also assumes what scrolling the display buffer will do. I should
think this is accepted practice that if you have a duplicate screen size
not viewed you might expect it should not do a smooth transition, but
instantly switch buffers. This is not, however, what the definition of
panning is. To pan is to transition over time. It is typically used to
allow for a larger graphics area that is written and you can move your
viewing port around that area.
> Mathias
>
>
>
> >
>
Chris
FBIOPAN_DISPLAY seems to result in an instantanous buffer switch. On
some of these devices however, when one tries to do
FBIOPUT_VSCREENINFO, it will be quite slow because it actually
reapplies all the fields instead of recognizing the changed fields and
applying them. This can result in an unfortunate blinking effect on
each frame update. In my experience, on x86 it is best to check if
FBIOPAN_DISPLAY is supported and use it if it is supported. If not,
drop back to FBIOPUT_VSCREENINFO. If neither works because setting up
the framebuffer for virtual panning failed or the driver simply does
not support it the memcpy trick seems to be functionally correct but
will suck extra cycles on every screen update.
On x86 anyway, if you would like to pan slowly instead of
instanteously over a large virtual framebuffer, I think you would have
to issue a series of FBIOPAN_DISPLAY calls (i.e., you use the ioctl to
implement a sw controlled panning fuction not to have the hardware pan
at its own pace).
I am not sure that it will be possible to have a completely platform
independent code sequence that will be effective on all platforms of
interest to everyone. Based on this discussion, I suspect that the
"best way to swap buffers without tearing or wasting clocks" will vary
with platform. Are there ideas for how to do platform ifdefs or some
other mechanism to avoid dueling tweaks to this part of the code?
Regards,
Chris
>
> - Show quoted text -
Mathias Agopian
On Nov 4, 9:53 am, Chris <chris.l.elf...@intel.com> wrote:
> On x86 devices with Intel integrated graphics (e.g., 865, 945, etc),
> FBIOPAN_DISPLAY seems to result in an instantanous buffer switch. On
> some of these devices however, when one tries to do
> FBIOPUT_VSCREENINFO, it will be quite slow because it actually
> reapplies all the fields instead of recognizing the changed fields and
> applying them. This can result in an unfortunate blinking effect on
> each frame update. In my experience, on x86 it is best to check if
> FBIOPAN_DISPLAY is supported and use it if it is supported. If not,
> drop back to FBIOPUT_VSCREENINFO. If neither works because setting up
> the framebuffer for virtual panning failed or the driver simply does
> not support it the memcpy trick seems to be functionally correct but
> will suck extra cycles on every screen update.
>
> On x86 anyway, if you would like to pan slowly instead of
> instanteously over a large virtual framebuffer, I think you would have
> to issue a series of FBIOPAN_DISPLAY calls (i.e., you use the ioctl to
> implement a sw controlled panning fuction not to have the hardware pan
> at its own pace).
implement the ioctl the "right way" for the features we want. The real
problem is that the linux fb driver doesn't have a well defined (or at
least not well documented) API and allow each driver to do things
differently. Reading fb.h, I see no guidance as to what these ioctl
should do exactly.
Also, I don't think we should put to much effort in working with buggy
drivers -- it is best to fix the driver instead; Most fb drivers don't
implement vsync properly for instance, but it is a *must have* for the
Android UI.
> I am not sure that it will be possible to have a completely platform
> independent code sequence that will be effective on all platforms of
> interest to everyone. Based on this discussion, I suspect that the
> "best way to swap buffers without tearing or wasting clocks" will vary
> with platform. Are there ideas for how to do platform ifdefs or some
> other mechanism to avoid dueling tweaks to this part of the code?
which has not yet been submitted. It will handle platform specific
things such as basic graphics acceleration, sensors, camera, etc...
I suppose, we could create a "display" hardware module with a well
defined and documented API that will handle the gory details of a
particular fb driver. I'm wondering if it is not overkill though.
Mathias
Chris
> We have started to work on a modular hardware abstraction mechanism,
> which has not yet been submitted. It will handle platform specific
> things such as basic graphics acceleration, sensors, camera, etc...
components (like some of these graphics bits) added as needed over
time. I would hate to overdesign such an interface up-front with all
the "gory details" only to find that just a few hooks are needed.
Matias writes:
> My take (and by experience), is that phone manufacturers will
> implement the ioctl the "right way" for the features we want. The real
> problem is that the linux fb driver doesn't have a well defined (or at
> least not well documented) API and allow each driver to do things
netbook/laptop and desktop, I could imagine running on framebuffer
devices to which source is unavailable to customize the ioctl. In
addition even when the driver is open source (hopefully the common
case), in many cases on x86 we try to use device drivers in as close
to an OOB (out of the box) as possible and work around any issues in
the user mode code (limiting the number of projects into which changes
need to be deployed... which may have other consumers that require
different behavior). It will be interesting to find the right balance
between putting patches such as this into Android projects (and
extending the hardware abstraction layer) versus driving them into
upstream projects. Admittedly, the Android kernel is an Android
project but I assume that a goal will be to minimize to some extent
its divergence from the root Linux kernel.
Thx,
Chris
>
> - Show quoted text -- Hide quoted text -
markgross
project is not limited to just handsets.
>
> > I am not sure that it will be possible to have a completely platform
> > independent code sequence that will be effective on all platforms of
> > interest to everyone. Based on this discussion, I suspect that the
> > "best way to swap buffers without tearing or wasting clocks" will vary
> > with platform. Are there ideas for how to do platform ifdefs or some
> > other mechanism to avoid dueling tweaks to this part of the code?
>
> We have started to work on a modular hardware abstraction mechanism,
> which has not yet been submitted. It will handle platform specific
> things such as basic graphics acceleration, sensors, camera, etc...
> I suppose, we could create a "display" hardware module with a well
> defined and documented API that will handle the gory details of a
> particular fb driver. I'm wondering if it is not overkill though.
more platforms, architectures and uses of android. BTW will google
have some design discussion on these or just drop the code on the
public when its ready?
--mgross
Yasushi SHOJI
> On Nov 1, 11:41 pm,McHargChris <chris.mch...@gmail.com> wrote:
> > while ago, I noticed that android was using FBIOPUT_VSCREENINFO (which
> > calls fb_set_par etc along with fb_pan_display) instead of
> > FBIOPAN_DISPLAY to flip the display. Any ideas on the reason for doing
> > it that way?
>
> I did it this way because some of the drivers on some hardware we used
> didn't support FBIOPAN_DISPLAY (and still don't). It looks like
> FBIOPAN_DISPLAY is often not implemented in comparison to
> FBIOPUT_VSCREENINFO.
>
> Ideally the code there should try FBIOPAN_DISPLAY and if that doesn't
> work, revert to FBIOPUT_VSCREENINFO.
flipping.
Does it means that pre-built SDL lib for Android emulator is modifiled
to match
this broken behavior?
--
yashi
David Turner
display things, so it certainly doesn't use FBIOPAN_DISPLAY.
Meanwhile, I think that's totally unrelated to your issue.
Benno
Cheers,
Benno
Sean McNeil
This is irrelevant on Freerunner now as I've implemented page flipping
in the kernel. I still have to change to use FBIOPAN_DISPLAY, though, as
the other ioctl does a complete refresh of settings and causes flashing.
Mathias Agopian
Sounds good.
Eventually, we'll need to abstract this out because there is no way to
know which ioctl to use. And in fact, one could imagine a board
without a /dev/graphics/fb driver at all. It sounds more and more like
a good candidate for the upcoming hardware abstraction layer.
mathias
Chris
abstraction. For the nearer term, I do have a patch to
EGLDisplaySurface.cpp that prefers PAN and if PAN is unavailable drops
back to PUT_VSCREENINFO. This patch also provides a fallback to
memcpyh if necessary. The patch is needed on some x86 platforms. We
are working thru the final steps of our internal legal reviews to let
us contribute to Android Open source (see
http://groups.google.com/group/android-porting/msg/bb9e38d8caa62441)
and hope I hope we can start submitting soon.
Thanks,
Chris
On Nov 17, 1:27 am, Mathias Agopian <pixelflin...@google.com> wrote:
Ben Leslie
Sure, I think it is still worth fixing for people porting to other
platforms. Either the code should be fixed, or things should error out
much earlier if the drivers doesn't have the correct capabilities.
Cheers,
Benno