Well that's a dodgy application on my part.. it now works sync'd with it ..

How should I do this without changing the kernel i810 module? is there an
way from the OpenGL level to do this that I could propogate down?

Dave.

Dave Airlie said:
>
> Nice one, that gets rid of my tearing - thanks Matthew,
>
> it works except now I get some jumpiness on my screen when a new texture
> is coming on, I've got 5 rotating reels of 4 textured quads and when the
> new ones are about to come on the top of the reel it seems to jump a
> bit...
>
> Not sure if the fullscreen would help here.. I need to time each render
> and see if this one takes a lot longer than the others..
>
> Dave.
>
> Sottek, Matthew J said:
>>
>> The easiest way to get rid of tearing is to make the ring buffer wait
>> before the back->front blit. This is a very simple mechanism that will
>> work even for windowed 3d, and if you are running just one 3d client
>> the wait time should not alter your performance much. Or rather,
>> the performance decrease should not be different than any other
>> "correct" rendering.
>>
>> Just add a GFXCMDPARSER_LOAD_SCAN_LINES_INCL and a
>> GFXCMDPARSER_WAIT_FOR_EVENT prior to the blit. This will hold the blit
>> as long as it would tear on the screen. Small windows will not have to
>> wait for a vblank, they only wait while the current scan
>> intersects the blit.
>>
>> If you don't want to do that, you can just use the wait for event to
>> block until the vblank as I mentioned before.
>>
>> This will make the rendering at least correct, you can then work on
>> the page flipping as an optimization for full screen.
>>
>>  -Matt
>>
>>
>>
>> -----Original Message-----
>> From: Dave Airlie [mailto:[EMAIL PROTECTED]]
>> Sent: Monday, December 16, 2002 6:57 PM
>> To: [EMAIL PROTECTED]
>> Cc: [EMAIL PROTECTED]
>> Subject: Re: [Dri-devel] [PATCH] i810 cleanup
>>
>>
>>
>> Well the i830 page flip code is using async flips, the main thing I
>> want to use page flipping for on my i815 is sync'ed flips so I don't
>> see the tearing that is so really obvious and gives people headaches..
>> (don't need to be getting sued here!!).
>>
>> It's not the timing I'm worried about it's the tearing, it can be slow
>> as long as its not really ugly...
>>
>> the i815 can't do async page flipping properly anyways there is a bug
>> in the silicon I would assume they fixed it for the i830 ...
>>
>> Also my current application is a single 3D window taking up the full
>> screen, I doubt I'll ever any 2d windows interfering which is handy
>> for me...
>>
>> My major issue now is finding a CVS tree which works for me on my
>> development platform that I can then add code to.
>>
>> As my patch doesn't affect anything other than cleanup can you check
>> it in?
>>
>> Dave.
>>
>>> The 830 page flipping code is turned off for some good reasons:
>>>     - I haven't seen it work without really visible corruption on the
>> flip
>>> -
>>> typically flashing and blank areas
>>>
>>>     - It isn't actually all that fast - there is a delay while
>> (presumably)
>>> the
>>> ramdac cache or fifo drains - this is comparable to the time to blit
>>> the
>>>  window itself.  The crossover point was about 300x300 on my test
>>> box,
>>> but  would vary for different machines.
>>>
>>>     - Because of the above, it is necessary to wait for the flip to
>> finish
>>> before
>>> clearing the backbuffer & starting the next frame, otherwise you see
>>> this  happen.  Actually this invalidates my explanation of the delay
>>> -- the fact  that you can see the clear implies that the ramdac is
>>> still grabbing new  values from the frontbuffer, so I don't really
>>> know what the delay arises from.
>>>
>>> Keith
>>
>>
>> --
>> David Airlie, Software Engineer
>> http://www.skynet.ie/~airlied / [EMAIL PROTECTED]
>> pam_smb / Linux DecStation / Linux VAX / ILUG person
>>
>>
>>
>>
>>
>> -------------------------------------------------------
>> This sf.net email is sponsored by:
>> With Great Power, Comes Great Responsibility
>> Learn to use your power at OSDN's High Performance Computing Channel
>> http://hpc.devchannel.org/
>> _______________________________________________
>> Dri-devel mailing list
>> [EMAIL PROTECTED]
>> https://lists.sourceforge.net/lists/listinfo/dri-devel
>
>
> --
> David Airlie, Software Engineer
> http://www.skynet.ie/~airlied / [EMAIL PROTECTED]
> pam_smb / Linux DecStation / Linux VAX / ILUG person
>
>
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:
> With Great Power, Comes Great Responsibility
> Learn to use your power at OSDN's High Performance Computing Channel
> http://hpc.devchannel.org/
> _______________________________________________
> Dri-devel mailing list
> [EMAIL PROTECTED]
> https://lists.sourceforge.net/lists/listinfo/dri-devel


-- 
David Airlie, Software Engineer
http://www.skynet.ie/~airlied / [EMAIL PROTECTED]
pam_smb / Linux DecStation / Linux VAX / ILUG person





-------------------------------------------------------
This sf.net email is sponsored by:
With Great Power, Comes Great Responsibility
Learn to use your power at OSDN's High Performance Computing Channel
http://hpc.devchannel.org/
_______________________________________________
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

Reply via email to