[Mesa-dev] [Bug 99781] Some Unity games fail assertion on startup in glXCreateContextAttribsARB

[bugzilla-daemon at freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=99781

--- Comment #2 from Ray Strode [halfline] <rstrode at redhat.com> ---
(In reply to Ray Strode [halfline] from comment #1) 
> I guess if it's gotten to the assertion things have already gone pair shaped
> because that's happening when trying to send the error.
So this isn't right I guess.  The game is doing a series of
glXCreateContextAttribsARB () calls to figure out what GL level / features are
available.  Failure is expected, but blown assertions aren't.

widen() is this:

static void widen(uint64_t *wide, unsigned int narrow)•              
{•                                                                   
→       uint64_t new = (*wide & ~((uint64_t)0xFFFFFFFFUL)) | narrow;•
→       *wide = new + (((uint64_t)(new < *wide)) << 32);•            
}•                                                                   

which is rather confusing but after staring at it for a bit i'll try to
deconstruct it:

The first parameter, wide, is an in-out variable.  It takes a 64-bit sequence
number as a template, gotten from X_DPY_GET_LAST_REQUEST_READ() and then
returns the output of the function back in the same variable.  The second
parameter, narrow, is a 32-bit sequence number.  X events only have room for
32-bit sequence numbers associated with them at the xlib level, so narrow is
that 32-bit input.  The goal is to recover the lost upper bits, treat that
32-bit sequence number as an offset into a 64-bit number.  We need to find the
upper base bits.  Those, are gleaned from the template passed in.

So the first line of the function extracts the upper 32-bits from the template
and applies them to the 32-bit number.  Now the 32-bit number has been given
its 64 bits back.  But there is a small possibility the 64-bit template and the
event don't actually share the same 32-bits.  new should always be greater than
the template when widened, because the template is X_DPY_GET_LAST_REQUEST_READ
() which is the last request we knew the X server read.  The last request we
knew the X server read should be smaller, because this new event is going to be
the new last request read; we're in a function that updates the last request
read counter known sequence number, and it's happening later in the function. 
If the last request previously accounted for is ending up bigger than this new
event then it means the upper 32-bits of the sequence number have after
actually incremented since then, and the template upper 32-bits are off by one.
So the second line is compensating for that.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/mesa-dev/attachments/20170630/31684cc7/attachment.html>