| Age | Commit message (Collapse) | Author |
|---|
|
Ensure no other thread is accessing a framebuffer when it is being destroyed by
acquiring both the global and per-framebuffer mutexes. Normal access only
needs the global lock to walk the linked list and acquire the per-framebuffer
mutex.
|
|
Fixes wglthreads -- the 2nd thread MakeCurrent call was trying to flush
the first thread context while still in use.
|
|
According to
http://blogs.msdn.com/oldnewthing/archive/2008/01/15/7113860.aspx
WM_SIZE is generated from WM_WINDOWPOSCHANGED by DefWindowProc so it
can be masked out by the application.
Also there were some weird bogus WM_SIZE 0x0 messages when starting
sharedtex_mt which we don't get like this.
|
|
Seriously.
|
|
These will come back in someday, when we can properly use them.
|
|
They have to cross into each other's registers.
|
|
(cherry picked from commit 88c01a15da5639dd68a6a0133724994cb66f1316)
|
|
As reported and initially tested by MrCooper.
|
|
|
|
|
|
|
|
plus it saves us a cacheline in the cso
|
|
reported by clang static analyzer
|
|
reported by clang static analyzer
|
|
found by the clang static analyzer
|
|
|
|
Fixes flush during validation, in case a buffer is double-validated.
|
|
|
|
|
|
Conflicts:
src/mesa/main/dlist.c
src/mesa/vbo/vbo_save_api.c
|
|
This is a tweak to a previous fix -- it's not necessary to actually
advertise this extension to prevent these games from crashing -- they
ignore the extension string anyway. It's sufficient to just have
GetProcAddress return some dummy function addresses for SwapInterval.
Given we don't really implement this funcitonality, this is a better
fix.
|
|
Some applications create several HDCs for the same window, so spite the WGL
API is geared towards HDCs it is not reliable searching by HDC.
|
|
AFAICT nobody will miss it.
|
|
|
|
|
|
This is okay since drm_api.h doesn't have any external
dependancies, one could make it only compile on platforms
that support drm.
|
|
Also just noticed that demos/copypix walks around the overlapping blit rules.
Bad, bad Mesa. :3
|
|
This makes demos/copypix better-looking. Horizontal dimensions are right now.
|
|
Note that trace debugging is temporarily gone. I'll rework it later.
|
|
|
|
|
|
|
|
Remove the drm_api from the functions in the softpipe and
i915simple drivers. Create wrapper functions in the
backends instead.
|
|
Conflicts:
src/mesa/vbo/vbo_exec_draw.c
|
|
This was only present for the sake of GL_ARB_shadow_ambient which we
never implemented in Gallium. If we someday want GL_ARB_shadow_ambient
we can implement it in the state tracker by adding a MAD after the
relevant TEX instructions.
|
|
buffer_flush_mapped_range.
|
|
buffer_flush_mapped_range.
When a buffer was mapped for write and no explicit flush range was provided
the existing semantics were that the whole buffer would be flushed, mostly
for backwards compatability with non map-buffer-range aware code.
However if the buffer was mapped/unmapped with nothing really written --
something that often happens with the vbo -- we were unnecessarily assuming
that the whole buffer was written.
The new PIPE_BUFFER_USAGE_FLUSH_EXPLICIT flag (based from ARB_map_buffer_range
's GL_MAP_FLUSH_EXPLICIT_BIT flag) allows to clearly distinguish the
legacy usage from the nothing written usage.
|
|
According to http://unixwiz.net/techtips/outputdebugstring.html that's
how big the buffer is.
The 512bytes limitation is in kernel mode.
|
|
Required as some applications
retrieve and call these functions regardless of the fact that we
don't advertise the extension and further more the results of
wglGetProcAddress are NULL.
|
|
mesa allocates both frontface and pointcoord registers within the fog
coordinate register, by using swizzling. to make it cleaner and easier
for drivers we want each of them in its own register. so when doing
compilation from the mesa IR to tgsi allocate new registers for both
and add new semantics to the respective declarations.
|
|
Do linear search only if prefix matches.
|
|
|
|
|
|
|
|
|
|
Never crashed on x86, ptx is in the same stack slot in either case.
Thanks to Bob Gleitsmann for catching this.
|
|
|
|
The gl_PointCoord attribute is currently expected to be in the fog coord
register's z/w components. This was never totally fleshed out though.
This is just some placeholder code.
|
|
|
|
|
