nouveau page_flip function implement not wait vblank, which cause screen garbage
Francisco Jerez
currojerez at riseup.net
Thu Oct 27 03:49:24 PDT 2011
Thomas Hellstrom <thomas at shipmail.org> writes:
> 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.
>
That's the case of the nouveau driver, and it's the reason that we don't
respect the API returning -EBUSY when there's an already scheduled flip
request. IMHO that should be up to the driver, or even better, the IOCTL
could be specified to block in case userspace is requesting more
simultaneous page-flips than the kernel driver can handle, in order to
make the resulting behavior consistent for userspace no matter which
implementation is being used.
> 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.
>
Yeah, it would be good to relax this restriction -- the nouveau driver
has never respected it because we'd end up lock-stepping the GPU (we
wouldn't be sending the next batch of commands until the one sent before
the flip had been completely processed), and it's just not necessary
because we take additional measures to make sure that flips and commands
sent to other hardware queues are properly ordered with respect to one
another.
> 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.
>
Yes, so the fact that the nouveau pageflip implementation doesn't sync
to vblank before flipping isn't even a bug as it stands.
> /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 at gmail.com> wrote:
>>
>>> On Tue, 2011-10-25 at 14:15 +0200, Francisco Jerez wrote:
>>>
>>>> Maarten Maathuis<madman2003 at gmail.com> writes:
>>>>
>>>>
>>>>> 2011/10/25 chris<wwzbwwzb at 163.com>:
>>>>>
>>>>>> 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 at 163.com> 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 at lists.freedesktop.org
>>>> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>>>>
>>>
>>> _______________________________________________
>>> dri-devel mailing list
>>> dri-devel at lists.freedesktop.org
>>> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>>>
>> _______________________________________________
>> dri-devel mailing list
>> dri-devel at lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>>
>
>
>
> _______________________________________________
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 229 bytes
Desc: not available
URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20111027/a627a592/attachment.pgp>
More information about the dri-devel
mailing list