summaryrefslogtreecommitdiffstats
path: root/src
Commit message (Collapse)AuthorAgeFilesLines
* 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" <mesa-stable@lists.freedesktop.org Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=93358 Signed-off-by: Ben Widawsky <benjamin.widawsky@intel.com> Tested-by: Matt Turner <mattst88@gmail.com> Reviewed-by: Jason Ekstrand <jason.ekstrand@intel.com>
* radeon/uvd: silence a warningMarek Olšák2016-02-101-0/+3
|
* r300g: silence warningsMarek Olšák2016-02-101-2/+0
|
* 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 <ian.d.romanick@intel.com> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=92363 Reviewed-by: Anuj Phogat <anuj.phogat@gmail.com>
* meta: Use internal functions for renderbuffer accessIan Romanick2016-02-102-14/+8
| | | | | Signed-off-by: Ian Romanick <ian.d.romanick@intel.com> Reviewed-by: Anuj Phogat <anuj.phogat@gmail.com>
* meta/decompress: Track renderbuffer using gl_renderbuffer instead of GL API ↵Ian Romanick2016-02-102-5/+11
| | | | | | | object handle Signed-off-by: Ian Romanick <ian.d.romanick@intel.com> Reviewed-by: Anuj Phogat <anuj.phogat@gmail.com>
* 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 <ian.d.romanick@intel.com> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=92363 Reviewed-by: Anuj Phogat <anuj.phogat@gmail.com>
* i965/meta: Use internal functions for renderbuffer accessIan Romanick2016-02-103-11/+8
| | | | | Signed-off-by: Ian Romanick <ian.d.romanick@intel.com> Reviewed-by: Anuj Phogat <anuj.phogat@gmail.com>
* 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 <ian.d.romanick@intel.com> Reviewed-by: Anuj Phogat <anuj.phogat@gmail.com>
* 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 <ian.d.romanick@intel.com> Reviewed-by: Anuj Phogat <anuj.phogat@gmail.com>
* 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 <ian.d.romanick@intel.com> Reviewed-by: Anuj Phogat <anuj.phogat@gmail.com>
* 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 <ian.d.romanick@intel.com> Reviewed-by: Anuj Phogat <anuj.phogat@gmail.com>
* mesa: Refactor renderbuffer_storage to make _mesa_renderbuffer_storageIan Romanick2016-02-102-39/+63
| | | | | | | | | Pulls the parts of renderbuffer_storage that aren't just parameter validation out into a function that can be called from other parts of Mesa (e.g., meta). Signed-off-by: Ian Romanick <ian.d.romanick@intel.com> Reviewed-by: Anuj Phogat <anuj.phogat@gmail.com>
* mesa: Refactor _mesa_framebuffer_renderbufferIan Romanick2016-02-102-18/+27
| | | | | | | | | | | This function previously was only used in fbobject.c and contained a bunch of API validation. Split the function into framebuffer_renderbuffer that is static and contains the validation, and _mesa_framebuffer_renderbuffer that is suitable for calling from elsewhere in Mesa (e.g., meta). Signed-off-by: Ian Romanick <ian.d.romanick@intel.com> Reviewed-by: Anuj Phogat <anuj.phogat@gmail.com>
* radeonsi: put image, fmask, and sampler descriptors into one arrayMarek Olšák2016-02-106-116/+138
| | | | | | | | | | | | | | | | | | | The texture slot is expanded to 16 dwords containing 2 descriptors. Those can be: - Image and fmask, or - Image and sampler state By carefully choosing the locations, we can put all three into one slot, with the fmask and sampler state being mutually exclusive. This improves shaders in 2 ways: - 2 user SGPRs are unused, shaders can use them as temporary registers now - each pair of descriptors is always on the same cache line v2: cosmetic changes: add back v8i32, don't load a sampler state & fmask at the same time Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com>
* winsys/radeon: fix the num_tile_pipes comment to silence warningsMarek Olšák2016-02-101-3/+3
|
* winsys/radeon: better explain the num_tile_pipes fixup for TAHITI (v2)Alexandre Demers2016-02-101-2/+4
| | | | | | | | v2: Clarify the relation between num_tiles_pipes and GB_TILE_MODE and the fix needed for Tahiti as suggested by Marek. Signed-off-by: Alexandre Demers <alexandre.f.demers@gmail.com> Signed-off-by: Marek Olšák <marek.olsak@amd.com>
* st/mesa: check ureg_create() retval in create_pbo_upload_vs()Samuel Pitoiset2016-02-101-0/+2
| | | | | | | | | | This avoids a possible NULL dereference because ureg_create() might return a NULL pointer. Spotted by coverity. Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com> Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com>
* freedreno/ir3: Get rid of nested functionsBernhard Rosenkränzer2016-02-101-15/+15
| | | | | | | This allows building Freedreno with clang Signed-off-by: Bernhard Rosenkränzer <bero@linaro.org> Signed-off-by: Rob Clark <robclark@freedesktop.org>
* 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 <chrisf@ijw.co.nz> 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 <apinheiro@igalia.com> Reviewed-by: Ben Widawsky <benjamin.widawsky@intel.com> Tested-by: Jordan Justen <jordan.l.justen@intel.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
* i965/gen8: Remove dead assertionTopi Pohjolainen2016-02-101-6/+0
| | | | | | | | | | | | | | The assertion is inside a condition mandating num_samples > 1 and therefore the first half of the constraint is always met. The second half in turn would only be applicable for single sampled case and moreover it is trying to falsely check against surface type instead of format. Subsequent patches will introduce proper support for the lossless compression and dropping this here makes the patches a little simpler. Signed-off-by: Topi Pohjolainen <topi.pohjolainen@intel.com> Reviewed-by: Ben Widawsky <benjamin.widawsky@intel.com>
* i965: Use constant pointer when checking for compressionTopi Pohjolainen2016-02-102-2/+2
| | | | | Signed-off-by: Topi Pohjolainen <topi.pohjolainen@intel.com> Reviewed-by: Ben Widawsky <benjamin.widawsky@intel.com>
* mesa: fix trivial comment typo in dlist.cBrian Paul2016-02-091-1/+1
|
* i965/vec4: Drop support for ATTR as an instruction destination.Kenneth Graunke2016-02-091-16/+0
| | | | | | | | | This is no longer necessary...and it doesn't make much sense to have inputs as destinations. Signed-off-by: Kenneth Graunke <kenneth@whitecape.org> Reviewed-by: Matt Turner <mattst88@gmail.com> Reviewed-by: Chris Forbes <chrisf@ijw.co.nz>
* i965/vec4/gs: Stop munging the ATTR containing gl_PointSize.Kenneth Graunke2016-02-092-23/+4
| | | | | | | | | | | | | | | | | | gl_PointSize is delivered in the .w component of the VUE header, while the language expects it to be a float (and thus in the .x component). Previously, we emitted MOVs to copy it over to the .x component. But this is silly - we can just use a .wwww swizzle and access it without copying anything or clobbering the value stored at .x (which admittedly is useless). Removes the last use of ATTR destinations. v2: Use BRW_SWIZZLE_WWWW, not SWIZZLE_WWWW (caught by GCC). Signed-off-by: Kenneth Graunke <kenneth@whitecape.org> Reviewed-by: Matt Turner <mattst88@gmail.com> Reviewed-by: Chris Forbes <chrisf@ijw.co.nz>
* i965: Apply VS attribute workarounds in NIR.Kenneth Graunke2016-02-098-117/+202
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch re-implements the pre-Haswell VS attribute workarounds. Instead of emitting shader code in the vec4 backend, we now simply call a NIR pass to emit the necessary code. This simplifies the vec4 backend. Beyond deleting code, it removes the primary use of ATTR as a destination. It also eliminates the requirement that the vec4 VS backend express the ATTR file in terms of VERT_ATTRIB_* locations, giving us a bit more flexibility. This approach is a little different: rather than munging the attributes at the top, we emit code to fix them up when they're accessed. However, we run the optimizer afterwards, so CSE should eliminate the redundant math. It may even be able to fuse it with other calculations based on the input value. shader-db does not handle non-default NOS settings, so I have no statistics about this patch. Note that the scalar backend does not implement VS attribute workarounds, as they are unnecessary on hardware which allows SIMD8 VS. v2: Do one multiply for FIXED rescaling and select components from either the original or scaled copy, rather than multiplying each component separately (suggested by Matt Turner). Signed-off-by: Kenneth Graunke <kenneth@whitecape.org> Reviewed-by: Matt Turner <mattst88@gmail.com> Reviewed-by: Chris Forbes <chrisf@ijw.co.nz>
* st/mesa: clarify some texture target code in st_cb_drawpix.cBrian Paul2016-02-091-3/+5
| | | | | | | | | | | Use st->internal_target instead of PIPE_TEXTURE_2D when choosing the texture format. Probably no real difference, but let's be consistent. Simplify a test when determining whether we need normalized texcoords. Add a new assertion. Reviewed-by: Roland Scheidegger <sroland@vmware.com>
* st/mesa: fix bitmap texture target code and simplify tex sampler stateBrian Paul2016-02-092-17/+17
| | | | | | | | | | | | | | | Bitmaps may be drawn with a PIPE_TEXTURE_2D or PIPE_TEXTURE_RECT resource as determined at context creation by checking if PIPE_CAP_NPOT_TEXTURES is supported. But many places in the bitmap code were hard-coded to use PIPE_TEXTURE_2D. Use st->internal_target instead. I think an older NV chip is the only case where a gallium driver does not support NPOT textures. Bitmap drawing was probably broken for that GPU. Also, we only need one sampler state with texcoord normalization set up according to st->internal_target. Reviewed-by: Roland Scheidegger <sroland@vmware.com>
* st/mesa: use MAX3() macro, as we do for sampler view code belowBrian Paul2016-02-091-1/+2
| | | | Reviewed-by: Roland Scheidegger <sroland@vmware.com>
* st/mesa: move some st_cb_drawpixels.c code, add commentsBrian Paul2016-02-091-17/+22
|
* mesa/readpix: Dedent former _mesa_readpixels() if blockNanley Chery2016-02-091-29/+29
| | | | | | | | Formatting patch split out for easy reviewing. Signed-off-by: Nanley Chery <nanley.g.chery@intel.com> Reviewed-by: Ian Romanick <ian.d.romanick@intel.com> Reviewed-by: Brian Paul <brianp@vmware.com>
* mesa/readpix: Don't clip in _mesa_readpixels()Nanley Chery2016-02-091-13/+7
| | | | | | | | The clipping is performed higher up in the call-chain. Signed-off-by: Nanley Chery <nanley.g.chery@intel.com> Reviewed-by: Ian Romanick <ian.d.romanick@intel.com> Reviewed-by: Brian Paul <brianp@vmware.com>
* mesa/readpix: Clip ReadPixels() area to the ReadBuffer'sNanley Chery2016-02-091-2/+5
| | | | | | | | | | | | | | | | | | | The fast path for Intel's ReadPixels() unintentionally omits clipping the specified area to a valid one. Rather than clip in various corner-cases, perform this operation in the API validation stage. The bug in intel_readpixels_tiled_memcpy() showed itself when the winsys ReadBuffer's height was smaller than the one specified by ReadPixels(). yoffset became negative, which was an invalid input for tiled_to_linear(). v2: Move clipping to validation stage (Jason) Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=92193 Reported-by: Marta Löfstedt <marta.lofstedt@intel.com> Cc: "11.0 11.1" <mesa-stable@lists.freedesktop.org> Signed-off-by: Nanley Chery <nanley.g.chery@intel.com> Reviewed-by: Ian Romanick <ian.d.romanick@intel.com> Reviewed-by: Brian Paul <brianp@vmware.com>
* mesa/image: Make _mesa_clip_readpixels() work with renderbuffersNanley Chery2016-02-091-5/+17
| | | | | | | | | v2: Use gl_renderbuffer::{Width,Height} (Jason) Cc: "11.0 11.1" <mesa-stable@lists.freedesktop.org> Signed-off-by: Nanley Chery <nanley.g.chery@intel.com> Reviewed-by: Ian Romanick <ian.d.romanick@intel.com> Reviewed-by: Brian Paul <brianp@vmware.com>
* i965/vec4: Plumb separate surfaces and samplers through from NIRJason Ekstrand2016-02-094-9/+23
| | | | Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
* i965/vec4: Separate the sampler from the surface in generate_texJason Ekstrand2016-02-091-5/+13
| | | | Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
* i965/fs: Plumb separate surfaces and samplers through from NIRJason Ekstrand2016-02-097-22/+46
| | | | Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
* i965/fs: Separate the sampler from the surface in generate_texJason Ekstrand2016-02-092-6/+15
| | | | Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
* i965/fs: Add an enum for keeping track of texture instruciton sourcesJason Ekstrand2016-02-093-44/+72
| | | | | | | These logical texture instructions can have a *lot* of sources. It's much safer if we have symbolic names for them. Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
* nir: Separate texture from sampler in nir_tex_instrJason Ekstrand2016-02-0914-18/+102
| | | | | | | | | | | | | This commit adds the capability to NIR to support separate textures and samplers. As it currently stands, glsl_to_nir only sets the texture deref and leaves the sampler deref alone as it did before and nir_lower_samplers assumes this. Backends can still assume that they are combined and only look at only at the texture index. Or, if they wish, they can assume that they are separate because nir_lower_samplers, tgsi_to_nir, and prog_to_nir all set both texture and sampler index whenever a sampler is required (the two indices are the same in this case). Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
* nir/tex_instr: Rename sampler to textureJason Ekstrand2016-02-0918-95/+95
| | | | | | | | | We're about to separate the two concepts. When we do, the sampler will become optional. Doing a rename first makes the separation a bit more safe because drivers that depend on GLSL or TGSI behaviour will be fine to just use the texture index all the time. Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
* nir: Add some braces around loops and ifsJason Ekstrand2016-02-091-5/+10
|
* i965: Explicitly write the "TR DS Cache Disable" bit at TCS EOT.Kenneth Graunke2016-02-093-3/+6
| | | | | | | | | | | | | | | | Bit 0 of the Patch Header is "TR DS Cache Disable". Setting that bit disables the DS Cache for tessellator-output topologies resulting in stitch-transition regions (but leaves it enabled for other cases). We probably shouldn't leave this to chance - the URB could contain garbage - which could result in the cache randomly being turned on or off. This patch makes the final EOT write 0 to the first DWord (which only contains this one bit). This ensures the cache is always on. Signed-off-by: Kenneth Graunke <kenneth@whitecape.org> Reviewed-by: Matt Turner <mattst88@gmail.com>
* freedreno/ir3: use const_index helpersRob Clark2016-02-091-3/+7
| | | | Signed-off-by: Rob Clark <robclark@freedesktop.org>
* nir: use const_index helpersRob Clark2016-02-0911-24/+23
| | | | | Signed-off-by: Rob Clark <robclark@freedesktop.org> Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
* ptn: use const_index helpersRob Clark2016-02-091-2/+2
| | | | | Signed-off-by: Rob Clark <robclark@freedesktop.org> Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
* ttn: use const_index helpersRob Clark2016-02-091-5/+5
| | | | | Signed-off-by: Rob Clark <robclark@freedesktop.org> Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
* ttn: small logic cleanupRob Clark2016-02-091-1/+1
| | | | | | | The only case where dim!=NULL is where op==load_ubo. But using op==load_ubo is less confusing. Signed-off-by: Rob Clark <robclark@freedesktop.org>
* gtn: use const_index helpersRob Clark2016-02-091-8/+9
| | | | | Signed-off-by: Rob Clark <robclark@freedesktop.org> Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
* nir: const_index helpersRob Clark2016-02-094-100/+191
| | | | | | | | | | | | | | Direct access to intr->const_index[n], where different slots have different meanings, is somewhat confusing. Instead, let's put some extra info in nir_intrinsic_infos[] about which slots map to what, and add some get/set helpers. The helpers validate that the field being accessed (base/writemask/etc) is applicable for the intrinsic opc, for some extra safety. And nir_print can use this to dump out decoded const_index fields. Signed-off-by: Rob Clark <robclark@freedesktop.org> Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
generated by cgit v1.1 at 2025-03-23 11:28:04 +0000