| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
|
|
_DLL is defined by MSVC when building against a DLL version of the CRT
library. It bears no relation to whether we are building a DLL or not. That
is, we can build a DLL against a static CRT, or a static lib against a
dynamicaly linked CRT. See more detail at
http://msdn.microsoft.com/en-us/library/2kzt1wy3.aspx
This gets DLL version of glut linking correctly both with MinGW and MSVC.
PS: GL/gl.h (and others) must be fixed too.
|
|
Trying to override windows headers is a recipe for disaster. Especially
when using with glew. Also the windows headers in recent MinGW are complete
enough that they don't need patching up.
|
|
DRI drivers can be build side by side with other non-DRI drivers, therefore
there is no need to build gallium twice.
|
|
Like ccache, but works on all OSes.
|
|
|
|
|
|
There was some wglGetProcAddress calls to setup extensions already, but
including glext caused many compilation errors in MinGW.
|
|
to return TRUE/FALSE if the st_framebuffer is valid, and if it is
return the surface/texture in the passed pointer.
|
|
|
|
Builds on windows now.
|
|
From glew 1.5.1 release.
|
|
GLEW does some defining/undefining of GLAPIENTRY making it unreliable. GLEW
should also be fixed, but removing the dependency on this symbol.
This also restores the ability for GLUT to be used with -fvisibility=hidden.
The downside of this is that ld warns of:
Warning: size of symbol `glutBitmapXXXXX' changed from 4 in glut_xxx.o to 16 in glut_xxxx.o
Due to the fonts being declared void * (*4 bytes), but defined as 16byte static
structure. I'll fix that in a later commit.
See also commits:
- f321f16e83cae427d6496c11955fd1c898d0395c
- d084982240bafba0169c4a6cacf02d45d6cfd8c1
|
|
windows.h header recent MinGW versions already declare the WGL API, and
including mesa_wgl.h actually cause build failures.
|
|
It creates problems in many libraries (glut, glew) which are not unicode
aware.
|
|
Conflicts:
windows/VC8/mesa/osmesa/osmesa.vcproj
windows/VC8/progs/demos/gears.vcproj
windows/VC8/progs/progs.sln
|
|
|
|
|
|
|
|
|
|
|
|
Oops.
|
|
|
|
This function does simple texture mapping so disable normal texture mapping
before we call _swrast_write_rgba_span() so that we don't do it twice.
|
|
See bug #17895. These assertions could be removed when this is resolved.
|
|
New static configs generate DLLs that do not have a dependency on the MSCVR*
DLL's.
|
|
This reverts commit bbda892c551e7d3f2d94cc877cc6e80f8568fa99.
Static configs rolled into regular project files (in next commit).
Provided by Karl Schultz.
|
|
|
|
|
|
There were several bugs in the infrastructure for these two routines.
1. GLX_ALIAS was incorrectly used. The function and its alias must be
identical! glXMakeContextCurrent / glXMakeCurrentReadSGI and
MakeContextCurrent had different parameters. This caused the last
parameter of MakeContextCurrent to get random values.
2. We based the implementation of glXMakeContextCurrent on the manual
page instead of the GLX spec. The GLX spec says that
glXMakeContextCurrent can be passed a Window as a drawable. When this
happens, it will behave just like glXMakeCurrentReadSGI or
glXMakeCurrent.
3. If there was a problem finding or creating the DRI drawable,
MakeContextCurrent would crash instead of returning an error.
This commit fixes all three issues, and fixes bug #18367 and bug #19625.
|
|
|
|
The upstream linux kernel headers and libdrm kernel headers disagree on the
tag name for the sarea struct: _drm_i915_sarea vs drm_i915_sarea. They
both typedef it to drm_i915_sarea_t though, so just use that.
|
|
It's been broken and deprecated for a while, so it's time to die. This has the
wonderful benefit of cleaning up the code a fair amount; making it marginally
less twisty.
I'm unsure if the for loops in IntelWindowMoved are still needed.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Make some compiler flags per-file.
Remove driverfuncs.c from osmesa project.
|
|
This commit is mostly just a cosmetic change that cleans-up the interfaces,
replacing pipe_winsys::surface_* calls by
/**
* Allocate storage for a display target surface.
*
* Often surfaces which are meant to be blitted to the front screen (i.e.,
* display targets) must be allocated with special characteristics, memory
* pools, or obtained directly from the windowing system.
*
* This callback is invoked by the pipe_screenwhen creating a texture marked
* with the PIPE_TEXTURE_USAGE_DISPLAY_TARGET flag to get the underlying
* buffer storage.
*/
struct pipe_buffer *(*surface_buffer_create)(struct pipe_winsys *ws,
unsigned width, unsigned height,
enum pipe_format format,
unsigned usage,
unsigned *stride);
Most drivers were updated but not all were tested. Use the softpipe pipe
driver and the xlib winsys changes as a reference when fixing other drivers.
|
|
|
|
This utility is useful for hardware that doesn't support HW index buffers.
It's a bit inefficient but appears to give a substantial performance gain,
as we can emit tri strips that would otherwise be split into triangles.
|
|
|
|
|
|
|
|
Dri drivers often may validate first a write drawable and then a read
drawable ("readable"). However, the hardware lock may be unlocked when
validating the readable, causing the write drawable status to be stale.
Drivers should use this macro instead when validating two drawables.
|
|
|
