summaryrefslogtreecommitdiffstats
path: root/src/mesa/drivers
Commit message (Collapse)AuthorAgeFilesLines
* i965: Delete the INTEL_SEPARATE_STENCIL override.Kenneth Graunke2013-10-131-27/+0
| | | | | | | | | This option was useful during initial development, but it's been ages since I've heard of anyone using it. Plus, Gen7+ mandates separate stencil, so it was really only useful on Sandybridge anyway. Signed-off-by: Kenneth Graunke <[email protected]> Reviewed-by: Ian Romanick <[email protected]>
* i965: Add a new brw_device_info structure.Kenneth Graunke2013-10-136-0/+150
| | | | | | | | | | | | | | | The idea is that struct brw_device_info should store statically-known information about hardware features. Using the new family name in the PCI ID table, we can easily grab the right structure. This is basically the equivalent of intel_device_info in the kernel. This patch also makes the new structure available from intel_screen, but nothing uses it. Right now, it looks very redundant with existing fields, but that will change. Signed-off-by: Kenneth Graunke <[email protected]> Reviewed-by: Ian Romanick <[email protected]>
* i965: Add the family name to the PCI ID table.Kenneth Graunke2013-10-131-1/+1
| | | | | | | | I removed this a while ago, since we never used it, but I'm finally resurrecting the idea in the next commits. Signed-off-by: Kenneth Graunke <[email protected]> Reviewed-by: Ian Romanick <[email protected]>
* i965: Remove #define name from PCI ID table.Kenneth Graunke2013-10-131-1/+1
| | | | | | | | | | Nothing uses the #define name, and it's not terribly useful - the numerical ID serves the same purpose. The only thing we could really do with it is generate slightly prettier preprocessed code. But who looks at that? Signed-off-by: Kenneth Graunke <[email protected]> Reviewed-by: Ian Romanick <[email protected]>
* i965: Pull most driconf option handling into a centralized function.Kenneth Graunke2013-10-132-47/+61
| | | | | | | | | | | | | Using a helper function clarifies the context initialization code. I would've liked to completely centralize it, but moving the optionCache code from intelInitExtensions into here would've required setting flags in the context, which seems like a waste. v2: Rebase for the introduction of disable_derivative_optimization. Signed-off-by: Kenneth Graunke <[email protected]> Reviewed-by: Ian Romanick <[email protected]>
* i965: Move a bunch of code from intelInitContext to brwCreateContext.Kenneth Graunke2013-10-132-50/+44
| | | | | | | | | | | | Now that intelInitContext isn't shared between i915 and i965, the split is fairly arbitrary. This patch moves a bunch of the basic context creation and generation checking code up to the top-level function (and slightly earlier). More will follow. Signed-off-by: Kenneth Graunke <[email protected]> Reviewed-by: Ian Romanick <[email protected]>
* i965: Update the comment about viewport hacks.Kenneth Graunke2013-10-131-1/+7
| | | | | | | It wasn't clear that this was necessary for EGL, or why. Signed-off-by: Kenneth Graunke <[email protected]> Reviewed-by: Ian Romanick <[email protected]>
* i965: Pull out INTEL_DEBUG handling into new intel_debug.[ch] files.Kenneth Graunke2013-10-135-128/+200
| | | | | | | | | | | | | Now that there isn't an intel_context structure, the split between brw_context.[ch] and intel_context.[ch] is rather awkward and arbitrary. Removing intel_context.[ch] seems desirable, but not everything really belongs in brw_context.[ch], either. Moving INTEL_DEBUG handling into separate intel_debug.[ch] files should make them relatively easy to find. Signed-off-by: Kenneth Graunke <[email protected]> Reviewed-by: Ian Romanick <[email protected]>
* i965: Rename brwCreateContext's error parameter to dri_ctx_error.Kenneth Graunke2013-10-131-3/+3
| | | | | | | | "error" is a very generic name. dri_ctx_error is the name used in intelInitContext(), which is more specific. Signed-off-by: Kenneth Graunke <[email protected]> Reviewed-by: Ian Romanick <[email protected]>
* dri: Move i965-specific context flag logic to dri common.Eric Anholt2013-10-132-8/+9
| | | | | Nobody else yet can do a forward context anyway, but others should be able to do debug contexts, and those would have just had no effect currently.
* i965: Turn on GLSL 1.50 and GL 3.2 support for i965 gen7.Paul Berry2013-10-122-2/+4
| | | | | | | | | | | | Geometry shaders were the last thing we needed to finish before turning on GLSL 1.50 and GL 3.2 support. They are now working well, with just a few piglit failures left to fix. Reviewed-by: Matt Turner <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]> Reviewed-by: Chris Forbes <[email protected]> Reviewed-by: Ian Romanick <[email protected]> Reviewed-by: Jordan Justen <[email protected]>
* i965: extend fast texture uploadFrank Henigman2013-10-101-69/+402
| | | | | | | | | | | | | | | | | | | | | Extend the fast texture upload from BGRA X-tiled to include RGBA, Alpha/Luminance, and Y-tiled. Speed improvements, measured with mesa demos teximage program, on 256 x 256 texture, in MB/s, on a Sandy Bridge (Ivy is comparable): before after increase BGRA/X-tiled 3266 4524 1.39x BGRA/Y-tiled 1739 3971 2.28x RGBA/X-tiled 474 4694 9.90x RGBA/Y-tiled 477 3368 7.06x L/X-tiled 1268 1516 1.20x L/Y-tiled 1439 1581 1.10x v2: Cosmetic changes only: reformat and reword comments, make doxygen-friendly, rename variables, use existing macros, add an assert. Signed-off-by: Frank Henigman <[email protected]> Reviewed-and-tested-by: Chad Versace <[email protected]>
* dri: Reference the global driver vtable once at screen init..Eric Anholt2013-10-102-14/+23
| | | | | | | | | | | This is part of the prep for megadrivers, which won't allow using a single global symbol due to the fact that there will be multiple drivers built into the same dri.so file. For that, we'll need screen init to take a reference to the driver to set up this vtable. v2: Fix two missed references to driDriverAPI. Reviewed-by: Kenneth Graunke <[email protected]> (v1)
* i965: Clean up error handling for context creation.Eric Anholt2013-10-104-34/+8
| | | | | | | | | | | | | | | The intel_screen.c used to be a dispatch to one of 3 driver functions, but was down to 1, so it was kind of a waste. In addition, it was trying to free all of the data that might have been partially freed in the kernel 3.6 check (which comes after intelInitContext, and thus might have had driverPrivate set and result in intelDestroyContext() doing work on the freed data). By moving the driverPrivate setup earlier, we can use intelDestroyContext() consistently and avoid such problems in the future. v2: Adjust the prototype of brwCreateContext to use the proper enum (fixing a compiler warning in some builds) Reviewed-by: Kenneth Graunke <[email protected]> (v1)
* intel: Remove silly check for !bufmgr.Eric Anholt2013-10-102-12/+0
| | | | | | | | If bufmgr didn't get created, then screen creation failed, and we never should have got here in the first place. This was added by Chris Wilson in 2010 with no explanation for why it would be needed. Reviewed-by: Kenneth Graunke <[email protected]>
* dri: Move API version validation into dri/common.Eric Anholt2013-10-1014-225/+112
| | | | | | | | | | | | | | | | | i965, i915, radeon, r200, swrast, and nouveau were mostly trying to do the same logic, except where they failed to. Notably, swrast had code that appeared to try to enable GLES1/2 but forgot to set api_mask (thus preventing any gles context from being created), and the non-intel drivers didn't support MESA_GL_VERSION_OVERRIDE. nouveau still relies on _mesa_compute_version(), because I don't know what its limits actually are, and gallium drivers don't declare limits up front at all. I think I've heard talk about doing so, though. v2: Compat max version should be 30 (noted by Ken) Drop r100's custom max version check, too (noted by Emil Velikov) Reviewed-by: Kenneth Graunke <[email protected]>
* dri: Merge drisw_util.c into dri_util.cEric Anholt2013-10-104-386/+48
| | | | | | | | | | | | The only important difference was not calling drmGetVersion, and making the swrast extension vtable. That doesn't justify duplicating the other 330 lines of code. v2: fix the scons build (code by Emil Velikov) v3: fix scons build with swrast-only (code by Emil Velikov) v4: Drop the new define I added, when we already have __NOT_HAVE_DRM_H. Signed-off-by: Emil Velikov <[email protected]>
* dri: Add an explanatory comment for an important driver entrypoint.Eric Anholt2013-10-101-0/+7
| | | | Reviewed-by: Kenneth Graunke <[email protected]>
* dri: Remove dead comment.Eric Anholt2013-10-101-4/+0
| | | | | | The code it was referencing was removed in 2010. Reviewed-by: Kenneth Graunke <[email protected]>
* i965/fs: Convert gen7 to using GRFs for texture messages.Eric Anholt2013-10-109-109/+170
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Looking at Lightsmark's shaders, the way we used MRFs (or in gen7's case, GRFs) was bad in a couple of ways. One was that it prevented compute-to-MRF for the common case of a texcoord that gets used exactly once, but where the texcoord setup all gets emitted before the texture calls (such as when it's a bare fragment shader input, which gets interpolated before processing main()). Another was that it introduced a bunch of dependencies that constrained scheduling, and forced waits for texture operations to be done before they are required. For example, we can now move the compute-to-MRF interpolation for the second texture send down after the first send. The downside is that this generally prevents remove_duplicate_mrf_writes() from doing anything, whereas previously it avoided work for the case of sampling from the same texcoord twice. However, I suspect that most of the win that originally justified that code was in avoiding the WAR stall on the first send, which this patch also avoids, rather than the small cost of the extra instruction. We see instruction count regressions in shaders in unigine, yofrankie, savage2, hon, and gstreamer. Improves GLB2.7 performance by 0.633628% +/- 0.491809% (n=121/125, avg of ~66fps, outliers below 61 dropped). Improves openarena performance by 1.01092% +/- 0.66897% (n=425). No significant difference on Lightsmark (n=44). v2: Squash in the fix for register unspilling for send-from-GRF, fixing a segfault in lightsmark. Reviewed-by: Kenneth Graunke <[email protected]> Acked-by: Matt Turner <[email protected]>
* i965/fs: Allocate more register classes on gen7.Eric Anholt2013-10-102-18/+30
| | | | | | | | | | | | | | | | For texturing from GRFs, we now have payloads of arbitrary sizes up to the message length limit. v2 (Kenneth Graunke): Rebase on intel_context -> brw_context change. v3: Add some comment text. v4: Change some magic 16s to BRW_MAX_MRF (noted by Ken). Leave the 11, which is the magic "max sampler message length". BRW_MAX_MRF sizing on the little int arrays is retained because I could see us needing to extend in the future if we move to GRFs for FB writes (those go to at least 12 long in a quick scan of the specs) Reviewed-by: Kenneth Graunke <[email protected]> (v2) Acked-by: Matt Turner <[email protected]>
* i965/fs: Use per-channel interference for register_coalesce_2().Eric Anholt2013-10-103-23/+26
| | | | | | | | | | This will let us coalesce into texture-from-GRF arguments, which would otherwise be prevented due to the live interval for the whole vgrf extending across all the MOVs setting up the channels of the message v2 (Kenneth Graunke): Rebase for renames. Reviewed-by: Kenneth Graunke <[email protected]>
* i965/fs: Use the new per-channel live ranges for dead code elimination.Eric Anholt2013-10-102-3/+16
| | | | | | v2 (Kenneth Graunke): Rebase on s/live_variables/live_intervals/g. Reviewed-by: Kenneth Graunke <[email protected]>
* i965/fs: Keep a copy of the live variables class around.Eric Anholt2013-10-103-12/+17
| | | | | | | | | | | Now optimization passes will be able to look at the per-channel ranges. v2: Rebase on various optimization pass changes. v3 (Kenneth Graunke): Rename live_variables to live_intervals; split introduction of invalidate_live_intervals() into a separate patch. Signed-off-by: Kenneth Graunke <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]>
* i965/fs: Invalidate live intervals when compacting; don't fix them.Kenneth Graunke2013-10-101-4/+1
| | | | | | | | | | | | When compacting the list of VGRFs, we patch up the live interval ranges (which are indexed by VGRF number). Unfortunately, once we make per-component data available, this will become too complicated to maintain. Instead, simply invalidate them. This was pulled out of a patch by Eric Anholt. Signed-off-by: Kenneth Graunke <[email protected]> Reviewed-by: Eric Anholt <[email protected]>
* i965/fs: Remove start/end aliases in compute_live_intervals().Kenneth Graunke2013-10-101-8/+6
| | | | | | | | | | | | | In compute_live_intervals(), start and end are shorter names for the virtual_grf_start and virtual_grf_end class members. Now that the fs_live_intervals class has arrays named start and end which are indexed by var, rather than VGRF, reusing the name is confusing. Plus, most of the code has been factored out, so using the long names isn't as inconvenient. Signed-off-by: Kenneth Graunke <[email protected]> Reviewed-by: Eric Anholt <[email protected]>
* i965/fs: Track live variable ranges on a per-channel level.Eric Anholt2013-10-102-74/+85
| | | | | | | | | | | This is the information we'll actually use to replace the virtual_grf_start[]/end[] arrays. No change in shader-db. v2 (Kenneth Graunke): Rebase; minor comment updates. Reviewed-by: Kenneth Graunke <[email protected]>
* i965/fs: Factor def[]/use[] setup out to a separate function.Eric Anholt2013-10-102-16/+43
| | | | | | | | | These blocks are about to grow some more code, and the indentation was getting out of hand. v2 (Kenneth Graunke): Rebase, minor typo fixes and style changes. Reviewed-by: Kenneth Graunke <[email protected]>
* i965/fs: Create a helper function for invalidating live intervals.Kenneth Graunke2013-10-107-15/+21
| | | | | | | | | | For now, this simply sets live_intervals_valid = false, but in the future it will do something more sophisticated. Based on a patch by Eric Anholt. Signed-off-by: Kenneth Graunke <[email protected]> Reviewed-by: Eric Anholt <[email protected]>
* i965/fs: Do live variables dataflow analysis on a per-channel level.Eric Anholt2013-10-102-17/+73
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This significantly improves our handling of VGRFs of size > 1. Previously, we only marked VGRFs as def'd if the whole register was written by a single instruction. Large VGRFs which were written piecemeal would not be considered def'd at all, even if they were ultimately completely written. Without being def'd, these were then marked "live in" to the basic block, often extending the range to preceding blocks and sometimes even the start of the program. The new per-component tracking gives more accurate live intervals, which makes register coalescing more effective. In the future, this should help with texturing from GRFs on Gen7+. A sampler message might be represented by a 2-register VGRF which holds the texture coordinates. If those are incoming varyings, they'll be produced by two PLN instructions, which are piecemeal writes. No reduction in shader-db instruction counts. However, code which prints the live interval ranges does show that some VGRFs now have smaller (and more correct) live intervals. v2: Rebase on current send-from-GRF code requiring adding extra use[]s. v3: Rebase on live intervals fix to include defs in the end of the interval. v4 (Kenneth Graunke): Rebase; split off a few preparatory patches; add lots of comments; minor style changes; rewrite commit message. v5 (Eric Anholt): whitespace nit. Written-by: Eric Anholt <[email protected]> [v1-3] Signed-off-by: Kenneth Graunke <[email protected]> [v4] Reviewed-by: Kenneth Graunke <[email protected]> Reviewed-by: Eric Anholt <[email protected]> (v4)
* i965/fs: Rename num_vars to num_vgrfs in live interval analysis.Kenneth Graunke2013-10-102-8/+7
| | | | | | | | | num_vars was shorthand for the number of virtual GRFs. num_vgrfs is a bit clearer. Plus, the next patch will introduce "vars" which are distinct from vgrfs. Signed-off-by: Kenneth Graunke <[email protected]> Reviewed-by: Eric Anholt <[email protected]>
* i965/fs: Short-circuit a loop in live variable analysis.Kenneth Graunke2013-10-101-5/+6
| | | | | | | | This has no functional effect, but should make subsequent changes a little simpler. Signed-off-by: Kenneth Graunke <[email protected]> Reviewed-by: Eric Anholt <[email protected]>
* i965/blorp: Allow format conversions for CopyTexSubImage.Kenneth Graunke2013-10-091-1/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | BLORP performs blits by drawing a rectangle with a shader that samples from the source texture, and writes color data to the destination. The sampler always returns 32-bit RGBA float data, regardless of the source format's component ordering or data type. Likewise, the render target write message takes 32-bit RGBA float data, and converts it appropriately. So the bulk of the work is already taken care of for us. This greatly accelerates a lot of CopyTexSubImage calls, and makes Legends of Aethereus playable on Ivybridge. At the default settings, LOA continually blits between SRGBA8888 (the window format) and RGBA16_FLOAT. Since neither BLORP nor our BLT paths supported this, it fell back to meta, spending 33% of the CPU in floorf() converting between floats and half-floats. v2: Use != instead of ^ (suggested by Ian). Note that only CopyTexSubImage is affected by this patch (caught by Eric). Signed-off-by: Kenneth Graunke <[email protected]> Reviewed-by: Ian Romanick <[email protected]> Reviewed-by: Chad Versace <[email protected]> Reviewed-by: Eric Anholt <[email protected]> Reviewed-by: Daniel Vetter <[email protected]>
* i965/blorp: Rework sRGB override behavior.Kenneth Graunke2013-10-092-9/+15
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The previous code for sRGB overrides assumes that the source and destination formats are equal, other than the color space. This won't be feasible when we add support for format conversions. Here are a few cases, and how the old code handled them: 1. RGB8 -> SRGB8, MSAA ==> SRGB8 -> SRGB8 2. RGB8 -> SRGB8, single ==> RGB8 -> RGB8 3. SRGB8 -> RGB8, MSAA ==> RGB8 -> RGB8 4. SRGB8 -> RGB8, single ==> SRGB8 -> SRGB8 Apparently, preserving the behavior of #1 is important. When doing a multisample to single-sample resolve, blending the samples together in an sRGB correct fashion results in a noticably higher quality image. It also is necessary to pass Piglit's EXT_framebuffer_multisample accuracy color tests. Paul, Eric, Anuj, and I talked about this, and aren't sure that it matters in the other cases. This patch preserves the behavior of #1, but otherwise reverts to doing everything in linear space, changing the behavior of case #4. Signed-off-by: Kenneth Graunke <[email protected]> Reviewed-by: Ian Romanick <[email protected]> Reviewed-by: Chad Versace <[email protected]> Reviewed-by: Eric Anholt <[email protected]> Reviewed-by: Daniel Vetter <[email protected]>
* i965/blorp: Explain why Z24 can't use a sensible format.Kenneth Graunke2013-10-091-1/+5
| | | | | | | | | | | | | | | | | We could conceivably use BRW_SURFACEFORMAT_R24_UNORM_X8_TYPELESS for Z24 source images, allowing conversions from Z24 to either Z16 or Z32F. Unfortunately, we can't use it for destination images since it isn't supported as a render target. Using different formats for sources or destinations would be painful, so for now, punt. Signed-off-by: Kenneth Graunke <[email protected]> Reviewed-by: Ian Romanick <[email protected]> Reviewed-by: Chad Versace <[email protected]> Reviewed-by: Eric Anholt <[email protected]> Reviewed-by: Daniel Vetter <[email protected]>
* i965/blorp: Use R32_FLOAT for Z32F surfaces.Kenneth Graunke2013-10-091-6/+8
| | | | | | | | | | | | | | | | | Currently, all that matters is that we copy the correct number of bits, so any format that has 32-bits of data will work fine. Once BLORP begins handling format conversions, the sampler will need to correctly interpret the data. We don't need a depth format, but we do need the right number of components and data type (FLOAT). For Z32F, this means using R32_FLOAT. Signed-off-by: Kenneth Graunke <[email protected]> Reviewed-by: Ian Romanick <[email protected]> Reviewed-by: Chad Versace <[email protected]> Reviewed-by: Eric Anholt <[email protected]> Reviewed-by: Daniel Vetter <[email protected]>
* i965/blorp: Use R16_UNORM for Z16 surfaces.Kenneth Graunke2013-10-091-6/+1
| | | | | | | | | | | | | | | | | Currently, all that matters is that we copy the correct number of bits, so any format that has 16-bits of data will work fine. Once BLORP begins handling format conversions, the sampler will need to correctly interpret the data. We don't need a depth format, but we do need the right number of components and data type (UNORM). For Z16, this means using R16_UNORM. Signed-off-by: Kenneth Graunke <[email protected]> Reviewed-by: Ian Romanick <[email protected]> Reviewed-by: Chad Versace <[email protected]> Reviewed-by: Eric Anholt <[email protected]> Reviewed-by: Daniel Vetter <[email protected]>
* i965/blorp: Add support for non-render-target formats.Kenneth Graunke2013-10-091-7/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Once blorp gains the ability to do format conversions, it's conceivable that the source format may be texturable but not supported as a render target. This would break Paul's code, which assumes that it can use the render_target_format array even for the source format. There are three ways to convert MESA_FORMAT enums to BRW_SURFACEFORMAT enums: 1. brw_format_for_mesa_format() This translates the Mesa format to the most equivalent BRW format. 2. brw->render_target_format[] This is used for renderbuffers, and handles the subset of formats that are renderable. However, it's not always equivalent, since it overrides a few non-renderable formats. For example, it converts B8G8R8X8_UNORM to B8G8R8A8_UNORM so it can be rendered to. 3. translate_tex_format() This is used for textures. It wraps brw_format_for_mesa_format(), but overrides depth textures, and one sRGB case on Gen4. BLORP has a fourth function, which uses brw->render_target_format[] and overrides depth formats (differently than translate_tex_format). This patch makes the BLORP function to use brw_format_for_mesa_format() for textures/source data, since not everything will be a render target. It continues using brw->render_target_format[] for render targets, since it needs the format overrides that provides. We don't use translate_tex_format() since the additional overrides are not useful or simply redundant. Signed-off-by: Kenneth Graunke <[email protected]> Reviewed-by: Ian Romanick <[email protected]> Reviewed-by: Chad Versace <[email protected]> Reviewed-by: Eric Anholt <[email protected]> Reviewed-by: Daniel Vetter <[email protected]>
* i965/blorp: Add an is_render_target parameter to surface_info::set.Kenneth Graunke2013-10-094-6/+8
| | | | | | | | | | | This allows us to determine whether we're setting up a format for the source (as a texture) or destination (as a render target). Signed-off-by: Kenneth Graunke <[email protected]> Reviewed-by: Ian Romanick <[email protected]> Reviewed-by: Chad Versace <[email protected]> Reviewed-by: Eric Anholt <[email protected]> Reviewed-by: Daniel Vetter <[email protected]>
* i965/blorp: Fix the register types on blorp's push constants.Eric Anholt2013-10-091-16/+16
| | | | | | | | | | The UD values were getting set up as floats. This happened to work out because they were used as the second argument where the first was a dword, and gen6+ doesn't do source conversions. But it did trigger fulsim warnings, and it meant if you used the push constant as the first operand you would have been disappointed. Reviewed-by: Paul Berry <[email protected]>
* i965: Fix 3D texture layout by more literally copying from the spec.Eric Anholt2013-10-091-55/+20
| | | | | | | | | Fixes 3 texelFetch tests in piglit all.tests on ivb, and cubemap npot on gm45. v2: Don't forget the gen4 DL=6 cubemap behavior. Cc: "9.1 9.2" <[email protected]> Reviewed-by: Chad Versace <[email protected]> (v1)
* i965: Don't forget the cube map padding on gen5+.Eric Anholt2013-10-091-7/+15
| | | | | | | | | | | We had a fixup for gen4's 3d-layout cubemaps (which, iirc, we'd experimentally found to be necessary!), but while the spec still requires it on gen5, we'd been missing it in the array-layout cubemaps. Cc: "9.1 9.2" <[email protected]> Reviewed-by: Ian Romanick <[email protected]> Reviewed-by: Chad Versace <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]>
* i965: keep SecHalf flag after register coalescingChia-I Wu2013-10-091-0/+1
| | | | | | | Copy sechalf to the new register, otherwise we would read wrong HW registers. Signed-off-by: Chia-I Wu <[email protected]> Reviewed-by: Eric Anholt <[email protected]>
* i965: allow SIMD8 sampler messages in SIMD16 modeChia-I Wu2013-10-091-1/+2
| | | | | | | | When the instruction to send the sampler message is forced uncompressed or sechalf, send SIMD8 one even in SIMD16 mode. Signed-off-by: Chia-I Wu <[email protected]> Reviewed-by: Eric Anholt <[email protected]>
* i965: make BRW_COMPRESSION_2NDHALF valid for brw_SAMPLEChia-I Wu2013-10-091-1/+16
| | | | | | | | | | | SIMD8 sampler messages are allowed in SIMD16 mode, and they could not work without BRW_COMPRESSION_2NDHALF. Later PRMs (gen5 and later) do not explicitly state whether BRW_COMPRESSION_2NDHALF is allowed, but they do have examples using send with SecHalf. It should be safe to assume SecHalf is valid. Signed-off-by: Chia-I Wu <[email protected]> Reviewed-by: Eric Anholt <[email protected]>
* i965: Initialize brw_blorp_const_color_program::prog_data.Vinson Lee2013-10-081-0/+2
| | | | | | | Fixes "Uninitialized scalar field" defect reported by Coverity. Signed-off-by: Vinson Lee <[email protected]> Reviewed-by: Paul Berry <[email protected]>
* i965: Fix a compiler warning about conservative depth enums.Eric Anholt2013-10-081-0/+2
| | | | Reviewed-by: Chris Forbes <[email protected]>
* i965/gs: Fixup gl_PointSize on entry to geometry shaders.Paul Berry2013-10-081-0/+17
| | | | | | | | | | | | | | | | gl_PointSize is stored in the w component of VARYING_SLOT_PSIZ, but the geometry shader infrastructure assumes that it should look for all geometry shader inputs of type float in the x component. So when compiling a geomtery shader that uses a gl_PointSize input, fix it up during the shader prolog by moving the w component to the x component. This is similar to how we emit fixups and workarounds for vertex shader attributes. Fixes piglit test spec/glsl-1.50/execution/geometry/core-inputs. Reviewed-by: Ian Romanick <[email protected]> Reviewed-by: Jordan Justen <[email protected]>
* gen7: Use logical, not physical, dims in 3DSTATE_DEPTH_BUFFER (v2)Chad Versace2013-10-072-4/+4
| | | | | | | | | | | | | | | | | In 3DSTATE_DEPTH_BUFFER, we set Width and Height to the miptree slice's physical dimensions. (Logical and physical dimensions may differ for multisample surfaces). However, in SURFACE_STATE, we always set Width and Height to the slice's logical dimensions. We should do the same for 3DSTATE_DEPTH_BUFFER, because the hw docs say so. No Piglit regressions (-x glx -x glean) on Ivybridge with Wayland. v2: No Piglit regressions, for real this time. Reviewed-by: Jordan Justen <[email protected]> Signed-off-by: Chad Versace <[email protected]>
* i965: Remove the "ARF" register file.Matt Turner2013-10-075-16/+6
| | | | | | | | The registers in the architecture register file don't share much in common, so there's no point in grouping them together. Use the HW_REG class instead. The vec4 backend already does this. Reviewed-by: Kenneth Graunke <[email protected]>
generated by cgit v1.2.3 (git 2.39.1) at 2024-12-25 21:38:58 +0000