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"  wrote:
>On Tue, 2011-10-25 at 14:15 +0200, Francisco Jerez wrote:
>> Maarten Maathuis  writes:
>> 
>> > 2011/10/25 chris :
>> >> 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  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

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

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

[Francisco Jerez]

Thomas Hellstrom  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"  wrote:
>>
>>> On Tue, 2011-10-25 at 14:15 +0200, Francisco Jerez wrote:
>>>  
 Maarten Maathuis  writes:


> 2011/10/25 chris:
>  
>> 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  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 

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"  wrote:
>
>> On Tue, 2011-10-25 at 14:15 +0200, Francisco Jerez wrote:
>>  
>>> Maarten Maathuis  writes:
>>>
>>>
 2011/10/25 chris:
  
> 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  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
>

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 skeg...@gmail.com wrote:
On Tue, 2011-10-25 at 14:15 +0200, Francisco Jerez wrote:
 Maarten Maathuis madman2...@gmail.com writes:
 
  2011/10/25 chris wwzbw...@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 wwzbw...@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

[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 Skeggsskeg...@gmail.com  wrote:
   

On Tue, 2011-10-25 at 14:15 +0200, Francisco Jerez wrote:
 

Maarten Maathuismadman2...@gmail.com  writes:

   

2011/10/25 chriswwzbw...@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,chriswwzbw...@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

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

[Francisco Jerez]

Thomas Hellstrom tho...@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 Skeggsskeg...@gmail.com  wrote:

 On Tue, 2011-10-25 at 14:15 +0200, Francisco Jerez wrote:
  
 Maarten Maathuismadman2...@gmail.com  writes:


 2011/10/25 chriswwzbw...@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,chriswwzbw...@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: 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 Hellstromtho...@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



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

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  writes:
> 
> > 2011/10/25 chris :
> >> 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  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

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"  wrote:
>2011/10/25 chris :
>> 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? 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, >old_fb_obj->pending_flip);
>>
>> ??? ret = dev_priv->display.queue_flip(dev, crtc, fb, obj);
>> ? 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(>base.link,
>> 6212?? >base.file_priv->event_list);
>> 6213 wake_up_interruptible(>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 at 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.

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

[Francisco Jerez]

Maarten Maathuis  writes:

> 2011/10/25 chris :
>> 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? 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.
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 229 bytes
Desc: not available
URL: 

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

[chris]

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  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, >old_fb_obj->pending_flip);

ret = dev_priv->display.queue_flip(dev, crtc, fb, obj);
  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(>base.link,
6212   >base.file_priv->event_list);
6213 wake_up_interruptible(>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!





-- next part --
An HTML attachment was scrubbed...
URL: 

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

[Maarten Maathuis]

2011/10/25 chris :
> 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? 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, >old_fb_obj->pending_flip);
>
> ??? ret = dev_priv->display.queue_flip(dev, crtc, fb, obj);
> ? 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(>base.link,
> 6212?? >base.file_priv->event_list);
> 6213 wake_up_interruptible(>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 at 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 madman2...@gmail.com wrote:
2011/10/25 chris wwzbw...@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 wwzbw...@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.

___
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]

Maarten Maathuis madman2...@gmail.com writes:

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


pgpGCtyUWX8Et.pgp
Description: PGP signature
___
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 madman2...@gmail.com writes:
 
  2011/10/25 chris wwzbw...@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 wwzbw...@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

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

[chris]

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, >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(>base.link,
6212   >base.file_priv->event_list);
6213 wake_up_interruptible(>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!


-- next part --
An HTML attachment was scrubbed...
URL: 

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

[chris]

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!


___
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 wwzbw...@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 wwzbw...@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.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel