Update user guide

pal1000 · Mar 21, 2018 · 30f6235 · 30f6235
1 parent 0c25a93
commit 30f6235
Showing 1 changed file with 6 additions and 2 deletions.
diff --git a/readme.md b/readme.md
@@ -12,13 +12,17 @@ Mesa 17.3.6 builds are now available in [releases section](https://github.com/pa
 The following Mesa3D drivers are shipped in each release:
 - [llvmpipe](https://www.mesa3d.org/llvmpipe.html) and softpipe bundle. file name: opengl32.dll. llvmpipe is the default desktop OpenGL driver. Both llvmpipe and softpipe are available for both x86 and x64. softpipe can be selected by setting environment variable GALLIUM_DRIVER=softpipe.
 - [swr](http://openswr.org/). File names: swrAVX.dll, swrAVX2.dll. An alternative desktop OpenGL driver developped by Intel.  Available for x64 only, x86 is [officially unsupported](https://bugs.freedesktop.org/show_bug.cgi?id=102564#c5). There are currently 2 DLLs, only one being loaded based on what the user CPU can do. 2 more will join soon matching the exting flavors of AVX512 instruction set, see issue [#2](https://github.com/pal1000/mesa-dist-win/issues/2). By default Mesa uses llvmpipe. You can switch to swr by setting GALLIUM_DRIVER environment variable value to swr either globally or in a batch file. See [How to set environment variables](#how-to-set-environment-variables).
-- [osmesa](https://www.mesa3d.org/osmesa.html). File name: osmesa.dll. 2 versions of osmesa, off-screen rendering driver. They are located in osmesa-gallium and osmesa-swrast subdirectories. Available for both x86 and x64. This driver is used in special cases by software that is designed to use Mesa code to render without any kind of winndow system or operating system dependency. swrast variant runs without LLVM JIT, being much slower than gallium version, but it has unique features.
+- [osmesa](https://www.mesa3d.org/osmesa.html). File name: osmesa.dll. 2 versions of osmesa, off-screen rendering driver. They are located in osmesa-gallium and osmesa-swrast subdirectories. Available for both x86 and x64. This driver is used in special cases by software that is designed to use Mesa code to render without any kind of winndow system or operating system dependency. osmesa gallium supports OpenGL 3.x anewer while osmesa swrast also known as osmesa classic only suports OpenGL 2.1 but it has some unique capabilities.
 - graw. File name: graw.dll. This is Mesa3D plug-in library. It is not a driver. Available for both x86 and x64. This is used in special cases by software that is designed to use Mesa code. While Mesa includes a full version bearing the build target of graw-gdi and a headless version bearing the build target of graw-null, only the full version is included. The headless version can be easily added upon request in a later release. 
 
 Build instructions, if you want to replicate my builds, are available [here](https://github.com/pal1000/mesa-dist-win/tree/master/buildscript).
 
 # Installation and usage
-Before running the installer close all programs that use Mesa if any is running. After running the installer you need to run the quick deployment utility located in the directory you installed Mesa. You only need to do this for programs you didn't deployed Mesa before as the quick deployment utility changes persist across upgrades and reinstallations. The quick deployment utility has a start-over mechanism so you can do all deployments you need in one go. The quick deployment utility will help you save storage and makes things easier as you won't have to manually copy DLLs from Mesa installation directory as it creates symlinks to whatever Mesa drivers you opt-in to use. This behavior ensures all programs that use Mesa use the same up-to-date version. Quick deployment utility only asks for path to directory containing application executable, if the app is 64-bit or 32-bit and the drivers you need. 32-bit applications have their names marked in Task Manager while running. Most applications will use mesa regardless of GPU capabilities, but some applications may be smart enough to load OpenGL from system directory only. Use [Federico Dossena](https://github.com/adolfintel)'s Mesainjector to workaround this issue: [Build guide](http://fdossena.com/?p=mesa/injector_build.frag), [VMWare ThinApp capture](http://fdossena.com/mesa/MesaInjector_Capture.7z). Since v17.0.1.391 in-place upgrade is fully supported. Since v17.0.1.391-2 S3 texture compression is supported. v17.0.4.391-1 requires uninstall of previous versions. Applications requiring OpenGL 3.1 or newer may need [Manual OpenGL context configuration](#manual-opengl-context-configuration).
+Before running the installer close all programs that use Mesa if any is running. After running the installer you will have access to 2 deployment options, both located in the directory you installed Mesa. 
+- A system-wide deployment tool. While intended for systems lacking hardware accelerated OpenGL support like virtual machines in cloud environments, it can also be used on any Windows system to replace the inbox software render OpenGL 1.1 driver extending OpenGL support for use cases where hardware accelerated OpenGL is not available, like RDP connections.  
+- A per-application deployment tool. You only need to use it for programs you didn't deployed Mesa before as the per-app deployment utility changes persist across upgrades and reinstallations. The quick deployment utility has a start-over mechanism so you can do all deployments you need in one go. The per-app deployment utility will help you save storage and makes things easier as you won't have to manually copy DLLs from Mesa installation directory as it creates symlinks to whatever Mesa drivers you opt-in to use. This behavior ensures all programs that use Mesa use the same up-to-date version. Per-app deployment utility only asks for path to directory containing application executable, if the app is 64-bit or 32-bit and the drivers you need. 32-bit applications have their names marked in Task Manager while running. Most applications will use mesa regardless of GPU capabilities, but some applications may be smart enough to load OpenGL from system directory only. Use [Federico Dossena](https://github.com/adolfintel)'s Mesainjector to workaround this issue: [Build guide](http://fdossena.com/?p=mesa/injector_build.frag), [VMWare ThinApp capture](http://fdossena.com/mesa/MesaInjector_Capture.7z). Upgrade from 17.3.5.501-1 and older versions breaks osmesa drivers deployments made with per-app deployment tool. You'll have to redo the osmesa deployments.
+
+Since v17.0.1.391 in-place upgrade is fully supported. Since v17.0.1.391-2 S3 texture compression is supported. v17.0.4.391-1 requires uninstall of previous versions. Applications requiring OpenGL 3.1 or newer may need [Manual OpenGL context configuration](#manual-opengl-context-configuration).
 
 # Manual OpenGL context configuration
 With release of [OpenGL 3.1](https://en.wikipedia.org/wiki/OpenGL#OpenGL_3.1) features marked as deprecated in OpenGL 3.0 have been removed. Most proprietary drivers opted to implement the exemption from this rule offered in the form of GL_ARB_compatibility extension. Due to complexity and especially lack of correct implementation tests, Mesa3D opted for an easier solution. Implemented core profile and core+forward compatible contexts introduced with OpenGL 3.2 as alternative to GL_ARB_compatibility to support OpenGL 3.0 and up and use the already existing compatibility context to implement GL_ARB_compatibility functionality slowly but steadly, but without official support. This implementation being unsupported is not exposed as GL_ARB_compatibility. Because of this, applications that only set compatibility OpenGL context won't get above OpenGL 3.0.