summaryrefslogtreecommitdiffstats
path: root/src/mesa/drivers
Commit message (Collapse)AuthorAgeFilesLines
* i965/vec4: Initialize force_writemask_all in vec4_builder().Matt Turner2016-02-171-1/+2
| | | | Reviewed-by: Francisco Jerez <[email protected]>
* i965/gen7: Use predicated rendering for indirect computeJordan Justen2016-02-172-14/+83
| | | | | | | | | | | | | | | | | | | | | | | | | | | On gen7 (Ivy Bridge, Haswell), we will get a GPU hang if an indirect dispatch is used, but one of the dimensions is 0. Therefore we use predicated rendering on the GPGPU_WALKER command to handle this case. Fixes piglit test: spec/arb_compute_shader/zero-dispatch-size From the ARB_compute_shader spec, under DispatchCompute: "If the work group count in any dimension is zero, no work groups are dispatched." And then for DispatchComputeIndirect: ... "is equivalent (assuming no errors are generated) to calling DispatchCompute with <num_groups_x>, <num_groups_y> and <num_groups_z>" ... Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=94100 Signed-off-by: Jordan Justen <[email protected]> Reviewed-by: Ben Widawsky <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]> Tested-by: Ilia Mirkin <[email protected]>
* i965: Set compute shader shared memory max to 64kJordan Justen2016-02-161-1/+1
| | | | | | | | | | | | | | | | | | | | See Ivy Bridge PRM, Volume 2, Part 2, 1.8.4 INTERFACE_DESCRIPTOR_DATA: DWORD 5, bits 20:16: "This field indicates how much shared local memory the thread group requires. The amount is specified in 4k blocks, but only powers of 2 are allowed: 0, 4k, 8k, 16k, 32k and 64k per half-slice." For Haswell, see Volume 2d, INTERFACE_DESCRIPTOR_DATA: DWORD 5, bits 20:16: With text identical to the Ivy Bridge PRM. For Broadwell, see Volume 2d, INTERFACE_DESCRIPTOR_DATA: DWORD 6, bits 20:16: With text identical to the Ivy Bridge PRM. Signed-off-by: Jordan Justen <[email protected]> Reviewed-by: Ben Widawsky <[email protected]>
* i965: Expose logic telling if non-msrt mcs is supportedTopi Pohjolainen2016-02-162-4/+13
| | | | | | | | | Alos use the opportunity to mark inputs constant. (Context has to be given as read-write to intel_miptree_supports_non_msrt_fast_clear() to support debug output). Signed-off-by: Topi Pohjolainen <[email protected]> Reviewed-by: Ben Widawsky <[email protected]>
* i965/gen9: Refactor msrt mcs initializationTopi Pohjolainen2016-02-161-14/+22
| | | | | | | | This will be re-used to initialize auxiliary buffers in lossless compression case. Signed-off-by: Topi Pohjolainen <[email protected]> Reviewed-by: Ben Widawsky <[email protected]>
* i965: Add a few assertions on lossless compressionTopi Pohjolainen2016-02-162-0/+9
| | | | | | | | | v2 (Ben): Use combination of msaa_layout and number of samples instead of introducing explicit type for lossless compression (intel_miptree_is_lossless_compressed()). Signed-off-by: Topi Pohjolainen <[email protected]> Reviewed-by: Ben Widawsky <[email protected]>
* i965: Add a flag telling color resolve pass to ignore CCS_ETopi Pohjolainen2016-02-163-2/+27
| | | | | | | | | v2 (Ben): Use combination of msaa_layout and number of samples instead of introducing explicit type for lossless compression (intel_miptree_is_lossless_compressed()). Signed-off-by: Topi Pohjolainen <[email protected]> Reviewed-by: Ben Widawsky <[email protected]>
* i965: Add resolve option for lossless compressionTopi Pohjolainen2016-02-162-1/+5
| | | | | | | | | v2 (Ben): Use combination of msaa_layout and number of samples instead of introducing explicit type for lossless compression (intel_miptree_is_lossless_compressed()). Signed-off-by: Topi Pohjolainen <[email protected]> Reviewed-by: Ben Widawsky <[email protected]>
* i965: Allow fast clear to be used with lossless compressionTopi Pohjolainen2016-02-162-2/+6
| | | | | | | | | | | | v2 (Ben): Use combination of msaa_layout and number of samples instead of introducing explicit type for lossless compression. v3 (Ben): Squash with "i965: Resolve color buffer also in lossless compression case" and clarify simple non-compressed fast clear case. Signed-off-by: Topi Pohjolainen <[email protected]> Reviewed-by: Ben Widawsky <[email protected]>
* i965: Add helper for detecting lossless compressionTopi Pohjolainen2016-02-162-0/+30
| | | | | Signed-off-by: Topi Pohjolainen <[email protected]> Reviewed-by: Ben Widawsky <[email protected]>
* Revert "i965: Restore vbo after color resolve during brw_try_draw_prims()"Topi Pohjolainen2016-02-161-9/+0
| | | | | | | | | | | | | This got pushed accidentally in the first place but wasn't reverted as it didn't regress piglit but instead fixed one newly introduced test exercising a corner in case in i965 driver. However, saving and restoring vertex buffer context is complicated and requires more thought. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=94150 Signed-off-by: Topi Pohjolainen <[email protected]> Reviewed-by: Tapani Palli <[email protected]>
* i965/bxt: Production thread countsBen Widawsky2016-02-151-10/+9
| | | | | | | | v2: Forgot to squash in the comment removal Signed-off-by: Ben Widawsky <[email protected]> Reviewed-by: Mark Janes <[email protected]> Reviewed-by: Jason Ekstrand <[email protected]>
* i965: Fix gl_DrawID in the vec4 backend.Kenneth Graunke2016-02-141-5/+5
| | | | | | | | | | | | brw_draw_upload.c uploads VertexID/InstanceID first, then DrawID. So we need to assign the attribute mapping in that order as well. Fixes the following Pigit tests with the vec4 backend: - arb_shader_draw_parameters-drawid vertexid - arb_shader_draw_parameters-drawid-indirect basevertex Signed-off-by: Kenneth Graunke <[email protected]> Reviewed-by: Kristian Høgsberg <[email protected]>
* glsl/types: Add support for function typesJason Ekstrand2016-02-133-0/+3
| | | | | | | | SPIR-V has a concept of a function type that's used fairly heavily. We could special-case function types in SPIR-V -> NIR but it's easier if we just add support to glsl_types. Reviewed-by: Jordan Justen <[email protected]>
* glsl/types: Rename sampler_type to sampled_typeJason Ekstrand2016-02-131-1/+1
| | | | | | | | It's a bit more descriptive since it is the base type that you get when you sample from it. Also, the next commit adds a bare "sampler" type and we need glsl_type::sampler_type available for a public static member. Reviewed-by: Jordan Justen <[email protected]>
* i965: Reupload push and pull constants when we get new shader image unit state.Francisco Jerez2016-02-131-0/+5
| | | | | | | | | | | Fixes several of the "dEQP-GLES31.functional.image_load_store*load_store*single_layer" dEQP tests that use image formats we implement using untyped surface messages. Cc: [email protected] Tested-by: Ilia Mirkin <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]>
* i965: fix MAX_COMPUTE_SHARED_SIZE constant valueSamuel Pitoiset2016-02-131-0/+1
| | | | | | | | | | | | MAX_COMPUTE_SHARED_SIZE should be set to 32768. This fixes a regression introduced in be27f77 (mesa: do not use a constant for MAX_COMPUTE_SHARED_SIZE). Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=94139 Signed-off-by: Samuel Pitoiset <[email protected]> Reviewed-by: Jordan Justen <[email protected]> Reviewed-by: Ilia Mirkin <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]>
* i965: Add means for limiting color resolvesTopi Pohjolainen2016-02-1310-17/+21
| | | | | | | | | | | | | | | | | Until now there has been only one type of color buffer that needs to resolved - namely single sampled fast clear. As even the sampler engine in GPU doesn't understand the associated meta data, the color values need to be always resolved prior to reading them. From SKL onwards there is new scheme supported called the lossless compression of single sampled color buffers. This is something that is understood by the sampling engine and therefore resolving of these types of buffers is not necessary before sampling. This patch adds means to make the distinction when considering if resolve is needed. Signed-off-by: Topi Pohjolainen <[email protected]> Reviewed-by: Ben Widawsky <[email protected]>
* i965: Refactor resolving of auxiliary modeTopi Pohjolainen2016-02-131-33/+29
| | | | | Signed-off-by: Topi Pohjolainen <[email protected]> Reviewed-by: Ben Widawsky <[email protected]>
* i965: Don't try to create aux buffer for non-msrt aux-bufferTopi Pohjolainen2016-02-131-10/+10
| | | | | | | | | | | | | | | | | | In addition to simply calling miptree_create() the higher level call intel_miptree_create() also considers if the buffer should be associated with an auxiliary buffer based on the given format. Here we are allocating an auxiliary buffer which in turn has such format that would mislead intel_miptree_create_layout() later on to try to associate the auxiliary buffer with an auxiliary buffer. To prevent this the actual buffer creation logic was split out into its own function. Lets invoke that instead. v2 (Ben): Do not signal msaa layout with explicit argument but using layout_flags instead. Signed-off-by: Topi Pohjolainen <[email protected]> Reviewed-by: Ben Widawsky <[email protected]>
* i965: Rename optimizer debug 00 filenameBen Widawsky2016-02-122-2/+2
| | | | | | | | This allows ls, and scripts to get the file names in the correct order of optimization. Signed-off-by: Ben Widawsky <[email protected]> Reviewed-by: Matt Turner <[email protected]>
* i965: Make brw_clear_cache NULL out stale program pointers.Kenneth Graunke2016-02-121-0/+15
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The L3 partitioning code tries to look at all programs - both render programs (VS/TCS/TES/GS/FS) and compute (CS). After calling brw_clear_cache, all prog_data pointers are invalid and point to freed data. The intention was that flagging the dirty bits for all programs would cause the next draw call to re-run the atoms for each program stage, uploading new programs and installing new, valid pointers. However, this doesn't quite work in our new multi-pipeline world. When drawing or dispatching a compute workload, we only consider the programs for the appropriate pipeline: drawing sets up VS/TCS/TES/GS/FS, but not CS, and vice versa. This leaves pointers dangling a bit longer than intended. The L3 configuration code tries to inspect the prog_data for all shader stages, so that we avoid having to reconfigure it when swapping back and forth between render and compute workloads. So we can't have dangling pointers. The fix is simple: have brw_clear_cache NULL out stale prog_data pointers, making it safe to inspect. The next L3 configuration pass will see either the render shaders or compute shader as missing for one go around, but will pick them up when both pipelines have run. In other words, we'll simply reconfigure L3 twice, which is safe, if a tiny bit wasteful - but then again, we just threw every compiled shader we had on the floor and started recompiling the from scratch, which is massively more wasteful, so it's not much of a concern. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=93790 Signed-off-by: Kenneth Graunke <[email protected]> Reviewed-by: Francisco Jerez <[email protected]> Reviewed-by: Jordan Justen <[email protected]>
* i915: include teximage.hKenneth Graunke2016-02-121-0/+1
| | | | To get _mesa_num_tex_faces() prototype.
* i965: include teximage.hBrian Paul2016-02-121-0/+1
| | | | To get _mesa_num_tex_faces() prototype.
* i965: Stop considering if msrt aux buffers need aux bufferTopi Pohjolainen2016-02-121-10/+10
| | | | | | | | | | | | | | | Auxiliary buffers are always created with sample number of zero which effectively prevents intel_miptree_create_layout() from trying to associate auxiliary buffers with auxiliary buffers. Now that there is more direct path available lets start using it instead and stop even checking for such (im)possibility. v2 (Ben): Do not signal msaa layout with explicit argument but using layout_flags instead. Signed-off-by: Topi Pohjolainen <[email protected]> Reviewed-by: Ben Widawsky <[email protected]>
* i965: Separate miptree creation from auxiliary buffer setupTopi Pohjolainen2016-02-121-17/+39
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Currently the logic allocating and setting up miptrees is closely combined with decision making when to re-allocate buffers in X-tiled layout and when to associate colors with auxiliary buffers. These auxiliary buffers are in turn also represented as miptrees and are created by the same miptree creation logic calling itself recursively. This means considering in vain if the auxiliary buffers should be represented in X-tiled layout or if they should be associated with auxiliary buffers again. While this is somewhat unnecessary, this doesn't impose any problems currently. Miptrees for auxiliary buffers are created as simgle-sampled fusing the consideration for multi-sampled compression auxiliary buffers. The format in turn is such that is not applicable for single-sampled fast clears (that would require accompaning auxiliary buffer). But once the driver starts to support lossless compression of color buffers the auxiliary buffer will have a format that would itself be applicable for lossless compression. This would be rather difficult and ugly to detect in the current miptree creation logic, and therefore this patch seeks to separate the association logic from the general allocation and setup steps. v2 (Ben): - Do not reconsider for X-tiling in intel_miptree_create() as it was just forced to Y-tiling in miptree_create(). - Do not drop checks for allocation failures. Signed-off-by: Topi Pohjolainen <[email protected]>
* i965: Isolate aligned dimensions for stencil onlyTopi Pohjolainen2016-02-121-15/+14
| | | | | | | | This makes the logic a little more explicit and helps to keep subsequent patches easier to read. Suggested-by: Ben Widawsky <[email protected]> Signed-off-by: Topi Pohjolainen <[email protected]>
* i965: Restore vbo after color resolve during brw_try_draw_prims()Topi Pohjolainen2016-02-121-0/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Part of brw_try_draw_prims() is a check to validate textures (brw_validate_textures()). In case of textures that currently have only level zero but are marked for mipmap generation, i965 driver will decide to replace the underlying buffer with a larger one capable of holding also the additional levels. This results into blit from the original buffer to the newly allocated (see intel_miptree_copy_teximage()). This blit is currently handled with blitter engine and hence it won't effect the ongoing draw operation. However, this blit in turn may trigger color resolve on the source buffer. In principle, this should be possible with fast cleared buffers but I only started hitting it when I enabled lossless compression (that reguires similar resolve to fast cleared buffers). Now, the color resolve is a meta operation and uses the same drawing path we are already in middle of. After quite a bit of debugging I realized that the resolve will modify the current vbo setup but it won't restore it afterwards resulting in the original draw call using wrong vertex data. When brw_try_draw_prims() gets called, the vbo logic in the Mesa core (see vbo_draw_arrays()) has just bound the vbo (see vbo_bind_arrays() and recalculate_input_bindings()). Color resolve operation will overwrite the vbo setup by calling vbo_bind_arrays() against the resolve rectangle (see brw_draw_rectlist()). Once the color resolve is done the vbo setup is left to the resolve rectangle state and the original drawing call yields bogus results. This patch aims to restore the original state after the color resolve by calling vbo_bind_arrays() yet again after the vertex array state in the core context have been restored. Now having said all this, I'd also like to state that I'm quite uncomfortable with the nested meta operations. Ths original draw call in this case is in fact a meta operation itself. It is a blit from level zero to level one when generating the additional mipmap levels (see _mesa_meta_GenerateMipmap()). Imagine the complexity if the blit in the middle from buffer to another would go to meta path also instead of blitter. I would very tempted to try to move all the resolves to happen before a meta operation is started. Additionally I still feel that work I did earlier in the spring/ summer time moving meta operations to use direct state upload bypassing the core context would make sense. v2: Force input recalculation by setting the flag explicitly v3: Do not attempt to restore vbo for opengles1 which doesn't support vertex buffer objects. Signed-off-by: Topi Pohjolainen <[email protected]>
* i965: Validate textures before altering driver stateTopi Pohjolainen2016-02-121-9/+9
| | | | | | | | | | Validation may kick off copies and subsequently color resolves. Color resolves (and the copies themselves if ending up in meta path) will overwrite the internal driver state but are not prepared to restore it. Instead of adding that capability the validation can be simply performed before the state is updated. Signed-off-by: Topi Pohjolainen <[email protected]>
* i965: Make brw_clear_cache flag all the bits on both pipelines.Kenneth Graunke2016-02-111-2/+6
| | | | | | | | | | | | | | | | Setting brw->ctx.NewDriverState and brw->ctx.NewGLState affects the dirty bits for the current pipeline. But, we need to flag everything dirty on *both* pipelines, so that when we switch back, we'll realize our programs are stale and re-upload them. To accomplish this, flag the saved state for both pipelines. Only one of them should matter, but this way we don't have to check which we need to set. It's harmless to set the other. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=93790 Signed-off-by: Kenneth Graunke <[email protected]> Reviewed-by: Jordan Justen <[email protected]> Tested-by: Ilia Mirkin <[email protected]>
* i965: Consider tessellation in get_pipeline_state_l3_weights.Kenneth Graunke2016-02-111-1/+6
| | | | | | | | I think this was just missed; Curro and I were probably writing code simultaneously and forgot to combine them at the end. Signed-off-by: Kenneth Graunke <[email protected]> Reviewed-by: Jordan Justen <[email protected]>
* i965: Split brw_upload_texture_surfaces into compute/render atoms.Kenneth Graunke2016-02-113-9/+34
| | | | | | | | | | | When uploading state for the compute pipeline, we don't want to look at VS/TCS/TES/GS/FS programs, as they might be stale, and aren't relevant anyway. Likewise, the render pipeline shouldn't look at CS. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=93790 Signed-off-by: Kenneth Graunke <[email protected]> Reviewed-by: Jordan Justen <[email protected]>
* i965/gs: Pass VerticesIn though prog_dataJason Ekstrand2016-02-113-1/+5
| | | | Reviewed-by: Kenneth Graunke <[email protected]>
* i965/fs: Pass usage of depth, W, and sample mask through prog_dataJason Ekstrand2016-02-116-20/+30
| | | | | | | | | | We really need to stop pulling information directly out of shaders for state setup. For one thing, if we want any sort of an on-disk shader cache, having all of this metadata in one place is going to be crucial. Also, passing it all through prog_data cleans up the compiler <-> state setup API substantially. Reviewed-by: Kenneth Graunke <[email protected]>
* i965/fs: Refactor setup_payload_gen6 to assume FSJason Ekstrand2016-02-113-15/+15
| | | | | | | | | It's extremely FS specific so the fact that we have a stage check in the middle of it is rather bogus. While were here, we rename setup_payload_gen4 and setup_payload_gen6 to make it obvious that they are both FS specific. Reviewed-by: Kenneth Graunke <[email protected]>
* i965: ir: dump floats as %-g rather than %f, so we can see denormalsChris Forbes2016-02-111-1/+1
| | | | | Signed-off-by: Chris Forbes <[email protected]> Reviewed-by: Ben Widawsky <[email protected]>
* i965/gen7: Require kernel cmd_parser 5 for ARB_compute_shaderJordan Justen2016-02-111-1/+2
| | | | | | | | The indirect dispatch registers were whitelisted in command parser version 5. (Version 5 is available as of Linux 4.4) Signed-off-by: Jordan Justen <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]>
* mesa: call build_program_resource_list inside Driver.LinkShaderMarek Olšák2016-02-111-0/+2
| | | | | | to allow LinkShader to free the GLSL IR. Reviewed-by: Ian Romanick <[email protected]>
* nir: Remove the const_offset from nir_tex_instrJason Ekstrand2016-02-102-25/+22
| | | | | | | | | | | When NIR was originally drafted, there was no easy way to determine if something was constant or not. The result was that we had lots of special-casing for constant values such as this. Now that load_const instructions are SSA-only, it's really easy to find constants and this isn't really needed anymore. Reviewed-by: Connor Abbott <[email protected]> Reviewed-by: Rob Clark <[email protected]>
* i965: Make sure we blit a full compressed blockBen Widawsky2016-02-101-0/+14
| | | | | | | | | | | | | | | | | | | | | | | | | This fixes an assertion failure in [at least] one of the Unreal Engine Linux demo/games that uses DXT1 compression. Specifically, the "Vehicle Game". At some point, the game ends up trying to blit mip level whose size is 2x2, which is smaller than a DXT1 block. As a result, the assertion in the blit path is triggered. It should be safe to simply make sure we align the width and height, which is sadly an example of compression being less efficient. NOTE: The demo seems to work fine without the assert, and therefore release builds of mesa wouldn't stumble over this. Perhaps there is some unnoticeable corruption, but I had trouble spotting it. Thanks to Jason for looking at my backtrace and figuring out what was going on. v2: Use NPOT alignment to make sure ASTC is handled properly (Ilia) Remove comment about how this doesn't fix other bugs, because it does. Cc: "11.0 11.1" <[email protected] Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=93358 Signed-off-by: Ben Widawsky <[email protected]> Tested-by: Matt Turner <[email protected]> Reviewed-by: Jason Ekstrand <[email protected]>
* meta/decompress: Don't pollute the renderbuffer namespaceIan Romanick2016-02-101-6/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | tl;dr: For many types of GL object, we can *NEVER* use the Gen function. In OpenGL ES (all versions!) and OpenGL compatibility profile, applications don't have to call Gen functions. The GL spec is very clear about how you can mix-and-match generated names and non-generated names: you can use any name you want for a particular object type until you call the Gen function for that object type. Here's the problem scenario: - Application calls a meta function that generates a name. The first Gen will probably return 1. - Application decides to use the same name for an object of the same type without calling Gen. Many demo programs use names 1, 2, 3, etc. without calling Gen. - Application calls the meta function again, and the meta function replaces the data. The application's data is lost, and the app fails. Have fun debugging that. Fixes piglit 'object-namespace-pollution glGetTexImage-compressed renderbuffer' test. Signed-off-by: Ian Romanick <[email protected]> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=92363 Reviewed-by: Anuj Phogat <[email protected]>
* meta: Use internal functions for renderbuffer accessIan Romanick2016-02-102-14/+8
| | | | | Signed-off-by: Ian Romanick <[email protected]> Reviewed-by: Anuj Phogat <[email protected]>
* meta/decompress: Track renderbuffer using gl_renderbuffer instead of GL API ↵Ian Romanick2016-02-102-5/+11
| | | | | | | object handle Signed-off-by: Ian Romanick <[email protected]> Reviewed-by: Anuj Phogat <[email protected]>
* i965/meta: Don't pollute the renderbuffer namespaceIan Romanick2016-02-103-16/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | tl;dr: For many types of GL object, we can *NEVER* use the Gen function. In OpenGL ES (all versions!) and OpenGL compatibility profile, applications don't have to call Gen functions. The GL spec is very clear about how you can mix-and-match generated names and non-generated names: you can use any name you want for a particular object type until you call the Gen function for that object type. Here's the problem scenario: - Application calls a meta function that generates a name. The first Gen will probably return 1. - Application decides to use the same name for an object of the same type without calling Gen. Many demo programs use names 1, 2, 3, etc. without calling Gen. - Application calls the meta function again, and the meta function replaces the data. The application's data is lost, and the app fails. Have fun debugging that. Signed-off-by: Ian Romanick <[email protected]> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=92363 Reviewed-by: Anuj Phogat <[email protected]>
* i965/meta: Use internal functions for renderbuffer accessIan Romanick2016-02-103-11/+8
| | | | | Signed-off-by: Ian Romanick <[email protected]> Reviewed-by: Anuj Phogat <[email protected]>
* i965/meta: Return struct gl_renderbuffer* from brw_get_rb_for_slice instead ↵Ian Romanick2016-02-104-24/+30
| | | | | | | of GL API handle Signed-off-by: Ian Romanick <[email protected]> Reviewed-by: Anuj Phogat <[email protected]>
* meta: Don't save or restore the renderbuffer bindingIan Romanick2016-02-102-7/+1
| | | | | | | | Nothing left in meta does anything with the RBO binding, so we don't need to save or restore it. The FBO binding is still modified. Signed-off-by: Ian Romanick <[email protected]> Reviewed-by: Anuj Phogat <[email protected]>
* meta: Use _mesa_CreateRenderbuffers instead of _mesa_GenRenderbuffers and ↵Ian Romanick2016-02-101-5/+4
| | | | | | | | | | | | _mesa_BindRenderbuffer This has the advantage that it does not pollute the global binding state. It also enables later patches that will stop calling _mesa_GenRenderbuffers / _mesa_CreateRenderbuffers which pollute the renderbuffer namespace. Signed-off-by: Ian Romanick <[email protected]> Reviewed-by: Anuj Phogat <[email protected]>
* i965/meta: Use _mesa_CreateRenderbuffers instead of _mesa_GenRenderbuffers ↵Ian Romanick2016-02-101-4/+3
| | | | | | | | | | | | and _mesa_BindRenderbuffer This has the advantage that it does not pollute the global binding state. It also enables later patches that will stop calling _mesa_GenRenderbuffers / _mesa_CreateRenderbuffers which pollute the renderbuffer namespace. Signed-off-by: Ian Romanick <[email protected]> Reviewed-by: Anuj Phogat <[email protected]>
* i965/blorp: Fix hiz ops on MSAA surfacesChris Forbes2016-02-101-2/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Two things were broken here: - The depth/stencil surface dimensions were broken for MSAA. - Sample count was programmed incorrectly. Result was the depth resolve didn't work correctly on MSAA surfaces, and so sampling the surface later produced garbage. Fixes the new piglit test arb_texture_multisample-sample-depth, and various artifacts in 'tesseract' with msaa=4 glineardepth=0. Fixes freedesktop bug #76396. Not observed any piglit regressions on Haswell. v2: Just set brw_hiz_op_params::dst.num_samples rather than adding a helper function (Ken). Signed-off-by: Chris Forbes <[email protected]> v3: moved the alignment needed for hiz+msaa to brw_blorp.cpp, as suggested by Chad Versace (Alejandro Piñeiro on behalf of Chris Forbes) Signed-off-by: Alejandro Piñeiro <[email protected]> Reviewed-by: Ben Widawsky <[email protected]> Tested-by: Jordan Justen <[email protected]> Reviewed-by: Jordan Justen <[email protected]>
generated by cgit v1.2.3 (git 2.39.1) at 2024-12-24 05:21:37 +0000