nouveau page_flip function implement not wait vblank, which cause screen garbage

nouveau page_flip function implement not wait vblank, which cause screen garbage

[chris]

[-- Attachment #1.1: Type: text/plain, Size: 1909 bytes --]

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.
 int
nouveau_crtc_page_flip(struct drm_crtc *crtc, struct drm_framebuffer *fb,
               struct drm_pending_vblank_event *event)
{
......
}
I study the i915 intel_crtc_page_flip implementation.
static int intel_crtc_page_flip(struct drm_crtc *crtc,
                struct drm_framebuffer *fb,
                struct drm_pending_vblank_event *event)
{
......

    ret = drm_vblank_get(dev, intel_crtc->pipe);
    if (ret)
        goto cleanup_objs;

    work->pending_flip_obj = obj;

    work->enable_stall_check = true;

    /* Block clients from rendering to the new back buffer until
     * the flip occurs and the object is no longer visible.
     */
    atomic_add(1 << intel_crtc->plane, &work->old_fb_obj->pending_flip);

    ret = dev_priv->display.queue_flip(dev, crtc, fb, obj);
    if (ret)
        goto cleanup_pending;
......
}

after vblank irq acquired, the interrupt isr will wakup the runqueue.
6159 static void do_intel_finish_page_flip(struct drm_device *dev,
6160                       struct drm_crtc *crtc)
6161 {
......
6211         list_add_tail(&e->base.link,
6212                   &e->base.file_priv->event_list);
6213         wake_up_interruptible(&e->base.file_priv->event_wait);
6214     }
6215
6216     drm_vblank_put(dev, intel_crtc->pipe);
6217


Is there anyone use the same  driver and found this issues can tell me "is it a bug"?

Thanks!



[-- Attachment #1.2: Type: text/html, Size: 3134 bytes --]

[-- Attachment #2: Type: text/plain, Size: 159 bytes --]

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re:nouveau page_flip function implement not wait vblank, which cause screen garbage

[chris]

[-- Attachment #1.1: Type: text/plain, Size: 2081 bytes --]

Can anyone give a suggestion, is wait-vblank fully implemented in page_flip() for nouveau drm driver?



At 2011-10-24 14:30:55,chris <wwzbwwzb@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.
 int
nouveau_crtc_page_flip(struct drm_crtc *crtc, struct drm_framebuffer *fb,
               struct drm_pending_vblank_event *event)
{
......
}
I study the i915 intel_crtc_page_flip implementation.
static int intel_crtc_page_flip(stru ct drm_crtc *crtc,
                struct drm_framebuffer *fb,
                struct drm_pending_vblank_event *event)
{
......

    ret = drm_vblank_get(dev, intel_crtc->pipe);
    if (ret)
        goto cleanup_objs;

    work->pending_flip_obj = obj;

    work->enable_stall_check = true;

    /* Block clients from rendering to the new back buffer until
     * the flip occurs and the object is no longer visible.
     */
    atomic_add(1 << intel_crtc->plane, &work->old_fb_obj->pending_flip);

    ret = dev_priv->display.queue_flip(dev, crtc, fb, obj);
 &nb sp;  if (ret)
        goto cleanup_pending;
......
}

after vblank irq acquired, the interrupt isr will wakup the runqueue.
6159 static void do_intel_finish_page_flip(struct drm_device *dev,
6160                       struct drm_crtc *crtc)
6161 {
......
6211         list_add_tail(&e->base.link,
6212                   &e->base.file_priv->event_list);
6213         wake_up_interruptible(&e->base.file_priv->event_wait);
6214     }
6215
6216     drm_vblank_put(dev, intel_crtc->pipe);
6217


Is there anyone use the same  driver and foun d this issues can tell me "is it a bug"?

Thanks!






[-- Attachment #1.2: Type: text/html, Size: 3661 bytes --]

[-- Attachment #2: Type: text/plain, Size: 159 bytes --]

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: nouveau page_flip function implement not wait vblank, which cause screen garbage

[Maarten Maathuis]

2011/10/25 chris <wwzbwwzb@163.com>:
> Can anyone give a suggestion, is wait-vblank fully implemented in
> page_flip() for nouveau drm driver?
>
>
> At 2011-10-24 14:30:55,chris <wwzbwwzb@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.
>  int
> nouveau_crtc_page_flip(struct drm_crtc *crtc, struct drm_framebuffer *fb,
>                struct drm_pending_vblank_event *event)
> {
> ......
> }
> I study the i915 intel_crtc_page_flip implementation.
> static int intel_crtc_page_flip(stru ct drm_crtc *crtc,
>                 struct drm_framebuffer *fb,
>                 struct drm_pending_vblank_event *event)
> {
> ......
>
>     ret = drm_vblank_get(dev, intel_crtc->pipe);
>     if (ret)
>         goto cleanup_objs;
>
>     work->pending_flip_obj = obj;
>
>     work->enable_stall_check = true;
>
>     /* Block clients from rendering to the new back buffer until
>      * the flip occurs and the object is no longer visible.
>      */
>     atomic_add(1 << intel_crtc->plane, &work->old_fb_obj->pending_flip);
>
>     ret = dev_priv->display.queue_flip(dev, crtc, fb, obj);
>  &am p;nb sp;  if (ret)
>         goto cleanup_pending;
> ......
> }
>
> after vblank irq acquired, the interrupt isr will wakup the runqueue.
> 6159 static void do_intel_finish_page_flip(struct drm_device *dev,
> 6160                       struct drm_crtc *crtc)
> 6161 {
> ......
> 6211         list_add_tail(&e->base.link,
> 6212                   &e->base.file_priv->event_list);
> 6213         wake_up_interruptible(&e->base.file_priv->event_wait);
> 6214     }
> 6215
> 6216     drm_vblank_put(dev, intel_crtc->pipe);
> 6217
>
>
> Is there anyone use the same  driver and foun d this issues can tell me "is
> it a bug"?
>
> Thanks!
>
>
>
>
>
>
>
> _______________________________________________
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>
>

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.

-- 
Far away from the primal instinct, the song seems to fade away, the
river get wider between your thoughts and the things we do and say.

Re:Re: nouveau page_flip function implement not wait vblank, which cause screen garbage

[chris]

It seems that nv04_graph_mthd_page_flip() was called from isr , and  page_flip ioctl only send a NV_SW_PAGE_FLIP  pushbuffer bo to gem. If you don't want the screen show garbage you must make sure not to change frontbuffer or backbuffer in GPU when nv_set_crtc_base()  is called, and not  change the frontbuffer context when it is rendering, am I right?
At 2011-10-25 13:45:29,"Maarten Maathuis" <madman2003@gmail.com> wrote:
>2011/10/25 chris <wwzbwwzb@163.com>:
>> Can anyone give a suggestion, is wait-vblank fully implemented in
>> page_flip() for nouveau drm driver?
>>
>>
>> At 2011-10-24 14:30:55,chris <wwzbwwzb@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.
>>  int
>> nouveau_crtc_page_flip(struct drm_crtc *crtc, struct drm_framebuffer *fb,
>>                struct drm_pending_vblank_event *event)
>> {
>> ......
>> }
>> I study the i915 intel_crtc_page_flip implementation.
>> static int intel_crtc_page_flip(stru ct drm_crtc *crtc,
>>                 struct drm_framebuffer *fb,
>>                 struct drm_pending_vblank_event *event)
>> {
>> ......
>>
>>     ret = drm_vblank_get(dev, intel_crtc->pipe);
>>     if (ret)
>>         goto cleanup_objs;
>>
>>     work->pending_flip_obj = obj;
>>
>>     work->enable_stall_check = true;
>>
>>     /* Block clients from rendering to the new back buffer until
>>      * the flip occurs and the object is no longer visible.
>>      */
>>     atomic_add(1 << intel_crtc->plane, &work->old_fb_obj->pending_flip);
>>
>>     ret = dev_priv->display.queue_flip(dev, crtc, fb, obj);
>>  &am p;nb sp;  if (ret)
>>         goto cleanup_pending;
>> ......
>> }
>>
>> after vblank irq acquired, the interrupt isr will wakup the runqueue.
>> 6159 static void do_intel_finish_page_flip(struct drm_device *dev,
>> 6160                       struct drm_crtc *crtc)
>> 6161 {
>> ......
>> 6211         list_add_tail(&e->base.link,
>> 6212                   &e->base.file_priv->event_list);
>> 6213         wake_up_interruptible(&e->base.file_priv->event_wait);
>> 6214     }
>> 6215
>> 6216     drm_vblank_put(dev, intel_crtc->pipe);
>> 6217
>>
>>
>> Is there anyone use the same  driver and foun d this issues can tell me "is
>> it a bug"?
>>
>> Thanks!
>>
>>
>>
>>
>>
>>
>>
>> _______________________________________________
>> dri-devel mailing list
>> dri-devel@lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>>
>>
>
>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.
>
>-- 
>Far away from the primal instinct, the song seems to fade away, the
>river get wider between your thoughts and the things we do and say.

Re: nouveau page_flip function implement not wait vblank, which cause screen garbage

[Francisco Jerez]

[-- Attachment #1.1.1: Type: text/plain, Size: 2187 bytes --]

Maarten Maathuis <madman2003@gmail.com> writes:

> 2011/10/25 chris <wwzbwwzb@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.

>>
>> At 2011-10-24 14:30:55,chris <wwzbwwzb@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.

[-- Attachment #1.2: Type: application/pgp-signature, Size: 229 bytes --]

[-- Attachment #2: Type: text/plain, Size: 159 bytes --]

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: nouveau page_flip function implement not wait vblank, which cause screen garbage

[Ben Skeggs]

On Tue, 2011-10-25 at 14:15 +0200, Francisco Jerez wrote:
> Maarten Maathuis <madman2003@gmail.com> writes:
> 
> > 2011/10/25 chris <wwzbwwzb@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@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@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re:Re: nouveau page_flip function implement not wait vblank, which cause screen garbage

[chris]

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@gmail.com> wrote:
>On Tue, 2011-10-25 at 14:15 +0200, Francisco Jerez wrote:
>> Maarten Maathuis <madman2003@gmail.com> writes:
>> 
>> > 2011/10/25 chris <wwzbwwzb@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@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@lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>
>
>_______________________________________________
>dri-devel mailing list
>dri-devel@lists.freedesktop.org
>http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: nouveau page_flip function implement not wait vblank, which cause screen garbage

[Thomas Hellstrom]

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@gmail.com>  wrote:
>    
>> On Tue, 2011-10-25 at 14:15 +0200, Francisco Jerez wrote:
>>      
>>> Maarten Maathuis<madman2003@gmail.com>  writes:
>>>
>>>        
>>>> 2011/10/25 chris<wwzbwwzb@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@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@lists.freedesktop.org
>>> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>>>        
>>
>> _______________________________________________
>> dri-devel mailing list
>> dri-devel@lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>>      
> _______________________________________________
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>    

Re: nouveau page_flip function implement not wait vblank, which cause screen garbage

[Francisco Jerez]

[-- Attachment #1.1.1: Type: text/plain, Size: 5996 bytes --]

Thomas Hellstrom <thomas@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@gmail.com>  wrote:
>>    
>>> On Tue, 2011-10-25 at 14:15 +0200, Francisco Jerez wrote:
>>>      
>>>> Maarten Maathuis<madman2003@gmail.com>  writes:
>>>>
>>>>        
>>>>> 2011/10/25 chris<wwzbwwzb@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@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@lists.freedesktop.org
>>>> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>>>>        
>>>
>>> _______________________________________________
>>> dri-devel mailing list
>>> dri-devel@lists.freedesktop.org
>>> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>>>      
>> _______________________________________________
>> dri-devel mailing list
>> dri-devel@lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>>    
>
>
>
> _______________________________________________
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

[-- Attachment #1.2: Type: application/pgp-signature, Size: 229 bytes --]

[-- Attachment #2: Type: text/plain, Size: 159 bytes --]

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: nouveau page_flip function implement not wait vblank, which cause screen garbage

[Thomas Hellstrom]

On 10/27/2011 12:49 PM, Francisco Jerez wrote:
> Thomas Hellstrom<thomas@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.
>
>    

I don't think you need to care about this restriction, since the next 
batch doesn't arrive for execution until the flip has happened. Waiting 
to submit in this case was never intended when there is GPU support to 
order the flip and the next batch of commands, and the waiting is only 
to protect against rendering errors.


>> 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.
>    

No it isn't. vmwgfx is doing (or going to do ) the same, since we can't 
sync to vblank currently. Also we are not holding rendering commands up, 
since the virtual GPU orders the flips and the next batch of commands.

/Thomas