FWIW, there was a quite long discussion / argument when the page flip
ioctl was designed, and at that time
I pointed out that there are hardware capable of pageflipping using the
fifo/pipe with optional VSYNC barriers, and that it is actually possible
to queue up a number of pageflips in the fifo. Not just one.
The interface description in drm_mode.h is somewhat different to what
was agreed upon, namely:
1) The command submission mechanism should block if a user tries to
render to a not yet flipped frontbuffer, and that would cause rendering
problems. For hardware that flips using a fifo / pipe, that's not really
a problem. Thus, any rendering errors due to rendering to a
not-yet-flipped frontbuffer is a kernel driver error.
The user-space app can avoid being blocked waiting using events.
2) The interface in itself doesn't require flips to be synced to
vblanks, as I understand it.
However, it should be possible to add a new flag
DRM_MODE_PAGE_FLIP_SYNC that tries to sync if at all possible.
/Thomas
On 10/27/2011 10:00 AM, chris wrote:
I think page_flip ioctl need to realize a synchronous mechanism to control fresh rate...!!!
At 2011-10-25 20:30:39,"Ben Skeggs"<skeggsb@xxxxxxxxx> wrote:
On Tue, 2011-10-25 at 14:15 +0200, Francisco Jerez wrote:
Maarten Maathuis<madman2003@xxxxxxxxx> writes:
2011/10/25 chris<wwzbwwzb@xxxxxxx>:
Can anyone give a suggestion, is wait-vblank fully implemented in
page_flip() for nouveau drm driver?
It's intentionally not implemented. The reason is that I wanted to
support non-vsync'ed vblank as well, and for vsync'ed blits we had to
think about a different mechanism for vblank synchronization anyway, so
I figured it didn't make that much sense to force vblank synchronization
directly from the pageflip ioctl.
+1 I deliberately didn't flip 1 bit in the NV50/NVC0 page flipping code
for this as well. The interface IMO is flawed. Though, that said, we
really should look at doing something properly for this, a lot of people
do want tear-free goodness.
Ben.
At 2011-10-24 14:30:55,chris<wwzbwwzb@xxxxxxx> wrote:
Dear,
I use NVidia Geforce 7300GT graphics card in my PC, and Linux 3.1rc4 kernel
code, git drm 2.4.36.
When I run the vbltest program, it prints "60HZ" which indicated the
implementation of drmWaitVBlank() and drm_vblank_wait() is correct.
But when I run modetest with option " -v -s 12:1280x1024" , it prints high
fresh rate up to "150 HZ" . I examing the code , and found that no waiting
vblank operation is processed in nouveau_crtc_ page_flip() function. The
screen produced lots of garbage and blink very much.
That's fine if by "garbage" you just mean it's tearing like crazy.
[...]
It seems to be, the actual page flipping is done by software method
(see nv04_graph_mthd_page_flip). There is one thing i'm unsure about
and that is that we wait for the rendering to be done to the current
frontbuffer and not the current backbuffer (this is only done if the
page flip channel is different than the rendering channel). Maybe
someone else can comment on that.
There's no need to wait for the backbuffer rendering to end because the
pageflip is always pushed through the last channel that has queued
rendering to it, so, the "waiting" is actually done by the GPU. The
waiting to the current frontbuffer (which in most cases is going to be a
cross-channel barrier instead of actual CPU waiting) is necessary for
the (rare) case where you have several channels trying to render to the
same pageflipped drawable, to make sure that the flips are properly
synchronized with respect each other.
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/dri-devel
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/dri-devel
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/dri-devel
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/dri-devel
