summaryrefslogtreecommitdiff
path: root/src/mesa/drivers/osmesa/osmesa.def
AgeCommit message (Collapse)AuthorFilesLines
2020-12-10mesa: Retire classic OSMesa.Eric Anholt1-16/+0
The classic OSMesa renders directly into user memory using src/mesa/swrast, while gallium OSMesa renders using softpipe or llvmpipe and copies out at glFlush() time. This would make gallium look like a worse choice for OSMesa, except that swrast is: 1) Painfully slow to render compared to llvmpipe 2) Incorrect at derivatives 3) Limited to GL 2.1 instead of GL 4.6 In my survey of OSMesa users, debian was the remaining holdout with classic OSMesa in use on hurd and some rare non-LLVM-supported architectures (sh4, alpha, etc.). As of today, they've switched to softpipe-based gallium OSMesa for them. To prevent people from running the wrong OSMesa (to the extent that running OSMesa can ever be the right thing), delete the classic version. Reviewed-by: Eric Engestrom <eric.engestrom@intel.com> Closes: #320 Closes: #877 Closes: #2297 Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/1243>
2016-07-07osmesa: Export OSMesaCreateContextAttribs.Mathias Fröhlich1-0/+1
Since the function is exported like any other public api function and put in the header as if you could link against it, export it also from shared objects. Signed-off-by: Mathias Fröhlich <Mathias.Froehlich@web.de> Reviewed-by: Brian Paul <brianp@vmware.com> Cc: "11.2 12.0" <mesa-stable@lists.freedesktop.org>
2016-05-30scons: build osmesa swrast and galliumAndreas Fänger1-0/+15
This patch makes it possible to build classic osmesa/swrast on windows again. It was removed in commit 69db422218b0264b5b8eef45bd003a2544e9cbd6. Although there is a gallium version of osmesa now, the swrast version still has more features lacking in llvmpipe, e.g. anisotropic filtering. Tested-by: Brian Paul <brianp@vmware.com> Reviewed-by: Brian Paul <brianp@vmware.com> [Emil Velikov: remove trailing whitespace] Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
2015-03-25scons: Don't build osmesa.Jose Fonseca1-15/+0
There doesn't seem much interest on osmesa on Windows, particularly classic osmesa. If there is indeed interest in osmesa on Windows, we should instead integrate src/gallium/targets/osmesa into SCons. Reviewed-by: Brian Paul <brianp@vmware.com>
2010-02-05osmesa: Add OSMesaColorClamp and OSMesaGetProcAddress to symbol defs.Brian Paul1-0/+2
Without this patch, the two symbols get an underscore prepended and an "@4" appended when compiling with VC8. Signed-off-by: Brian Paul <brianp@vmware.com> (cherry picked from commit e65029e9b32ddabea0ec583c04484345b40f1557)
2007-04-24assorted fixes for Windows/VC8Karl Schultz1-1/+1
2001-11-29main trunk is now 4.1Karl Schultz1-1/+1
2001-11-29update to version 4.0Karl Schultz1-1/+1
2001-09-21Make osmesa a DLL instead of a static lib (Windows). This is moreKarl Schultz1-0/+13
consistent with the other modules and platforms. It also makes the API and linkage on Windows more consistent.