-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Jesse Barnes wrote:
> On Friday, September 28, 2007 11:02 am Ian Romanick wrote:
>> Jesse Barnes wrote:
>>> On Wednesday, September 26, 2007 6:20 pm Ian Romanick wrote:
>>>> I do have one question now. What happens (or is intended to
>>>> happen) if the currently bound drawable is not a window?
>> Any thoughts on this?
>
> No, I'm not sure what should happen in this case. Doing a vblank sync'd
> buffer swap or vblank wait on an offscreen drawable doesn't make much
> sense does it? In what cases might those calls occur?
The spec doesn't say that an application can't call glXGetViewSyncSGI
when a pbuffer is bound, so you can be sure that someone does.
>> I was thinking of something like:
>>
>> if (pdraw == NULL) {
>> return GLX_BAD_CONTEXT;
>> }
>>
>> if (pdraw->getMSC != NULL) {
>> ....
>> } else if (psc->driScreen.getMSC != NULL) {
>> ....
>> }
>>
>> return (ret == 0) ? 0 : GLX_BAD_CONTEXT;
>
> Ok, that looks good. I'll fix it up.
I take that back. I looked at the unpatched code (instead of just
looking at the patch). The code already returns GLX_BAD_CONTEXT if the
return from __glXGetCurrentContext is NULL. This means that pdraw
*cannot* be NULL.
>> I only have a couple other comments.
>>
>> 1. As Michael pointed out, anything in the driver that accesses
>> pdraw->getMSC needs to check the API version first.
>
> Done (I'll do a quick double check though).
>
>> 2. The comment in the function header that the MSC "will never
>> decrease" should be amended. I should be able to guarantee that it
>> will never decrease for a given drawable, With two displays at
>> different refresh rates, an application could see two calls to getMSC
>> for different drawables return decreasing values.
>
> Done.
>
>> 3. I'm not very familiar with how the Intel hardware works, but does
>> the code guarantee that the MSC won't decrease if a window is moved
>> from one display to another?
>
> No, in that case the MSC will change and possibly decrease. But drivers
> can handle that case by tracking which output a given drawable is on
> (or mostly on), so that the drawable is sync'd to the right value.
That's bad. The MSC for a drawable should never decrease. I can easily
envision cases where that would cause problems for apps.
Drivers will have to make sure that getMSC returns values that only
increase. We can easily do that by keeping two values in the drawable
private. One value tracks a base MSC, and the second value tracks the
initial MSC on the current pipe when the base MSC was set. The driver's
getMSC would then return "base + (pipe_current_MSC - pipe_base_MSC)".
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)
iD8DBQFG/VskX1gOwKyEAw8RAkObAKCbs0Lv0FDSV175cBY2wJ6WQlHtrwCgmsXM
+cqEexR02GHLJVGLhTh786Y=
=1NXb
-----END PGP SIGNATURE-----
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
--
_______________________________________________
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
