Francisco Jerez
ad38ba1134
This reverts to using the oword block read messages for uniform pull constant loads, as used to be the case until4c1fdae0a0. There are two important differences though: Now the L3 cacheability bits are set up correctly for UBOs (since11f5d8a5d4), and we target the constant cache instead of the data cache. The latter used to get no L3 way allocation on boot on all platforms that existed at the time, so oword read messages wouldn't get cached on L3 regardless of the MOCS bits, what probably explains the apparent slowness of oword fetches. Constant cache loads seem to perform better than SIMD4x2 sampler loads in a number of cases, they alleviate some of the cache thrashing caused by the competition with textures for the L1/L2 sampler caches, and they allow fetching up to 128B worth of constants with a single oword fetch message. Note that IVB devices suffer from a hardware bug that leads to serialization of L3 read requests overlapping the same cacheline as result of a (on IVB buggy) mechanism of the L3 to preserve coherency. Since read requests for matching cachelines from any L3 client are not pipelined, throughput may decrease in cases where there are no non-overlapping requests left in the queue that can be processed between them. This situation should be relatively uncommon as long as we make sure that we don't use the 1/2 oword messages in cases where the shader intends to read from any other location of the same cacheline at some other point. This is generally a good idea anyway on all generations because using the 1 and 2 oword messages is expected to waste bandwidth since the minimum L3 request size for the DC is exactly 4 owords (i.e. one cacheline). A future commit will have this effect. I haven't been able to find any real-world example where this would still result in a regression on IVB, but if someone happens to find one it shouldn't be too difficult to add an IVB-specific check to have it fall back to the sampler cache for pull constant loads. Note that on SKL+ this change has the additional benefit of reducing the register footprint of pull constant loads. The following table summarizes the effect of the whole series on several shader-db stats: Total instructions Total cycles BWR: 4571248 -> 4568342 (-0.06%) 123375740 -> 123373296 (-0.00%) ELK: 3989020 -> 3985402 (-0.09%) 98757068 -> 98754058 (-0.00%) ILK: 6383591 -> 6376787 (-0.11%) 143649910 -> 143648914 (-0.00%) SNB: 7528395 -> 7501446 (-0.36%) 103503796 -> 102460370 (-1.01%) IVB: 6949221 -> 6943317 (-0.08%) 60592262 -> 60584422 (-0.01%) HSW: 6409753 -> 6403702 (-0.09%) 60609070 -> 60604414 (-0.01%) BDW: 8043467 -> 7976364 (-0.83%) 68427730 -> 68483042 (0.08%) CHV: 8045019 -> 7977916 (-0.83%) 68297426 -> 68352756 (0.08%) SKL: 8204037 -> 7939086 (-3.23%) 66583900 -> 65624378 (-1.44%) Lost->Gained Total spills Total fills BWR: 5 -> 5 1488 -> 1488 (0.00%) 1957 -> 1957 (0.00%) ELK: 5 -> 5 1489 -> 1489 (0.00%) 1958 -> 1958 (0.00%) ILK: 1 -> 4 1449 -> 1449 (0.00%) 1921 -> 1921 (0.00%) SNB: 0 -> 0 549 -> 549 (0.00%) 52 -> 52 (0.00%) IVB: 13 -> 3 1271 -> 1271 (0.00%) 1162 -> 1162 (0.00%) HSW: 11 -> 0 1271 -> 1271 (0.00%) 1162 -> 1162 (0.00%) BDW: 12 -> 0 1340 -> 1340 (0.00%) 1452 -> 1452 (0.00%) CHV: 12 -> 0 1340 -> 1340 (0.00%) 1452 -> 1452 (0.00%) SKL: 0 -> 120 1269 -> 375 (-70.45%) 1563 -> 690 (-55.85%) v3: Non-trivial rebase. Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
File: docs/README.WIN32 Last updated: 21 June 2013 Quick Start ----- ----- Windows drivers are build with SCons. Makefiles or Visual Studio projects are no longer shipped or supported. Run scons libgl-gdi to build gallium based GDI driver. This will work both with MSVS or Mingw. Windows Drivers ------- ------- At this time, only the gallium GDI driver is known to work. Source code also exists in the tree for other drivers in src/mesa/drivers/windows, but the status of this code is unknown. Recipe ------ Building on windows requires several open-source packages. These are steps that work as of this writing. - install python 2.7 - install scons (latest) - install mingw, flex, and bison - install pywin32 from here: http://www.lfd.uci.edu/~gohlke/pythonlibs get pywin32-218.4.win-amd64-py2.7.exe - install git - download mesa from git see http://www.mesa3d.org/repository.html - run scons General ------- After building, you can copy the above DLL files to a place in your PATH such as $SystemRoot/SYSTEM32. If you don't like putting things in a system directory, place them in the same directory as the executable(s). Be careful about accidentially overwriting files of the same name in the SYSTEM32 directory. The DLL files are built so that the external entry points use the stdcall calling convention. Static LIB files are not built. The LIB files that are built with are the linker import files associated with the DLL files. The si-glu sources are used to build the GLU libs. This was done mainly to get the better tessellator code. If you have a Windows-related build problem or question, please post to the mesa-dev or mesa-users list.