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!
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!
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.
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.
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.
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
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
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 Maathuismadman2003@gmail.com writes:
2011/10/25 chriswwzbwwzb@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,chriswwzbwwzb@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
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:
- 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.
- 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 Maathuismadman2003@gmail.com writes:
2011/10/25 chriswwzbwwzb@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,chriswwzbwwzb@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
On 10/27/2011 12:49 PM, Francisco Jerez wrote:
Thomas Hellstromthomas@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:
- 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.
- 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@lists.freedesktop.org
-
Ben Skeggs -
chris -
Francisco Jerez -
Maarten Maathuis -
Thomas Hellstrom