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

[Thomas Hellstrom <thomas@shipmail.org>]

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
>