summaryrefslogtreecommitdiffstats
path: root/src/mesa/drivers/common
Commit message (Collapse)AuthorAgeFilesLines
* meta: Disable dithering during glGenerateMipmapChad Versace2017-01-031-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | Fixes tests 'dEQP-GLES3.functional.texture.mipmap.*.generate.rgba5551*' on Intel Broadwell 0x1616. The GL 4.5 spec describes the algorithm of glGenerateMipmap as: The contents of the derived images are computed by repeated, filtered reduction of the level base image. [...] No particular filter algorithm is required, though a box filter is recommended as the default filter. Consider a texture for which all pixels are identical at level 0. From the spec's description above, one may reasonably assume that the "filtered reduction" of level 0 produces a new miplevel for which again all pixels are identical. For any 2x2 subspan of identical pixels, it is difficult to see how the "filtered reduction" of that subspan can produce a pixel that differs from the source pixels. Dithering during _mesa_meta_GenerateMipmap() violated that reasonable assumption. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=99210 Reviewed-by: Kenneth Graunke <kenneth@whitecape.org> Cc: mesa-stable@lists.freedesktop.org
* i965: Delete the meta-base CopyImageSubData implementationJason Ekstrand2016-12-052-317/+0
| | | | | | | | | | | | | | | | | | | When I originally implemented the ARB_copy_image extension, the fast-path was written in meta using texture views. This path only worked if both images were uncompressed color images. All of the other cases fell back to the blitter or, in the worst case, mapping and memcpy on the CPU. Now that we have the blorp path, it handles all copies ever and the old meta, blitter, and CPU paths are only used on gen5 and below. The primary reason why we needed the meta path (apart from having a slow blitter on later hardware) was to handle multisampling which gen5 and earlier don't support anyway. Since the blitter is reasonably fast on gen5, we can just delete the meta path and get rid of all that terrible code. If we decide that we're ok with just disabling ARB_copy_image on gen5 and earlier (I personally am), then we could get rid of another 300 lines or so of semi-hairy code. Reviewed-by: Anuj Phogat <anuj.phogat@gmail.com>
* st/mesa/glsl/nir/i965: make use of new gl_shader_program_data in ↵Timothy Arceri2016-11-191-2/+3
| | | | | | gl_shader_program Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
* meta/GetTexSubImage: Account for GL_PACK_SKIP_IMAGES on compressed texturesEduardo Lima Mitev2016-11-151-3/+17
| | | | | | | | | | | | This option was being ignored when packing compressed 3D and cube textures. Fixes CTS test (on gen8+): * GL45-CTS.gtf32.GL3Tests.packed_pixels.packed_pixels_pixelstore v2: Drop API checks. v3 (Ken): Just apply the existing code in more cases. Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
* drivers/meta: Accept GL_TEXTURE_3D as target for tex image decompressionEduardo Lima Mitev2016-10-281-4/+0
| | | | | | | | | | | | | | | | | | An assert is currently raised, preventing decompression of a texture image into a GL_TEXTURE_3D target. I have not found any spec wording that would explain this, or implementation detail that would prevent it. And in any case, the driver should not cause a crash upon user input arguments. Fixes most failing subcases in CTS tests: * GL44-CTS.gtf32.GL3Tests.packed_pixels.packed_pixels_pixelstore * GL45-CTS.gtf32.GL3Tests.packed_pixels.packed_pixels_pixelstore These tests were crashing the driver before. Now they just fail, but due to an unrelated issue affecting 2 out of the 45 test subcases. No regressions observed against piglit or CTS-GL. Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
* meta: remove remaining tabs in meta.cTimothy Arceri2016-10-261-49/+49
| | | | Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
* st/mesa/r200/i915/i965: eliminate gl_fragment_programTimothy Arceri2016-10-262-6/+6
| | | | | | | | | | Here we move OriginUpperLeft and PixelCenterInteger into gl_program all other fields have been replace by shader_info. V2: Don't use anonymous union/structs to hold vertex/fragment fields suggested by Ian. Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
* mesa/i965/i915/r200: eliminate gl_vertex_programTimothy Arceri2016-10-262-6/+6
| | | | | | | Here we move the only field in gl_vertex_program to the ARB program fields in gl_program. Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
* mesa: replace gl_framebuffer::_IntegerColor wih _IntegerBuffersBrian Paul2016-10-131-1/+1
| | | | | | | | | | | Use a bitmask to indicate which color buffers are integer-valued, rather than a bool. Also, the old field was mis-computed. If an integer buffer was followed by a non-integer buffer, the _IntegerColor field was wrongly set to false. This fixes the new piglit gl-3.1-mixed-int-float-fbo test. Reviewed-by: Marek Olšák <marek.olsak@amd.com>
* meta: Always do GenerateMipmaps in linear colorspace.Kenneth Graunke2016-08-251-2/+10
| | | | | | | | | | | | When generating mipmaps for sRGB textures, force both decode and encode, so the filtering is done in linear colorspace, regardless of settings. Fixes a WebGL conformance test in Chrome: https://www.khronos.org/registry/webgl/sdk/tests/conformance2/textures/misc/tex-srgb-mipmap.html?webglVersion=2 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=97322 Signed-off-by: Kenneth Graunke <kenneth@whitecape.org> Reviewed-by: Topi Pohjolainen <topi.pohjolainen@intel.com>
* mesa: Rename "texturebarrier" source files to "barrier".Francisco Jerez2016-08-241-2/+2
| | | | | | | In preparation for collecting all pipeline barrier GL entry points into a single source file. Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
* meta: Make Meta's BlitFramebuffer() follow the GL 4.4 sRGB rules.Kenneth Graunke2016-08-081-54/+30
| | | | | | | | | | Just avoid whacking GL_FRAMEBUFFER_SRGB altogether, so we respect the application's setting. This appears to work. v2: Update one more comment (requested by Ian). Signed-off-by: Kenneth Graunke <kenneth@whitecape.org> Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
* mesa: add numLevels, numSamples to Driver.TestProxyTexImage()Brian Paul2016-07-151-3/+3
| | | | | | | | | | | | | So that the function can work properly with glTexStorage(), where we know how many mipmap levels there are. And so we can compute storage for MSAA textures. Also, remove the obsolete texture border parameter. A subsequent patch will update _mesa_test_proxy_teximage() to use these new parameters. Reviewed-by: Anuj Phogat <anuj.phogat@gmail.com>
* meta/texsubimage: tex_image is always non-null, avoid confusing codeIlia Mirkin2016-07-111-1/+1
| | | | | | | | Probably a copy-paste from mesa_meta_pbo_GetTexSubImage where tex_image may apparently be null. Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu> Reviewed-by: Eric Engestrom <eric.engestrom@imgtec.com>
* glsl/main: remove unused params and make function staticTimothy Arceri2016-06-301-1/+1
| | | | Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
* glsl/mesa: split gl_shader in twoTimothy Arceri2016-06-301-1/+1
| | | | | | | | | | | | | | | | | There are two distinctly different uses of this struct. The first is to store GL shader objects. The second is to store information about a shader stage thats been linked. The two uses actually share few fields and there is clearly confusion about their use. For example the linked shaders map one to one with a program so can simply be destroyed along with the program. However previously we were calling reference counting on the linked shaders. We were also creating linked shaders with a name even though it is always 0 and called the driver version of the _mesa_new_shader() function unnecessarily for GL shader objects. Acked-by: Iago Toral Quiroga <itoral@igalia.com>
* mesa: Use bitmask/ffs to iterate enabled clip planes.Mathias Fröhlich2016-06-161-12/+10
| | | | | | | | | | | Replaces an iterate and test bit in a bitmask loop by a loop only iterating over the bits set in the bitmask. v2: Use _mesa_bit_scan{,64} instead of open coding. v3: Use u_bit_scan{,64} instead of _mesa_bit_scan{,64}. Reviewed-by: Brian Paul <brianp@vmware.com> Signed-off-by: Mathias Fröhlich <Mathias.Froehlich@web.de>
* mesa/glsl: stop using GL shader type internallyTimothy Arceri2016-06-162-11/+6
| | | | | | | | | | | | Instead use the internal gl_shader_stage enum everywhere. This makes things more consistent and gets rid of unnecessary conversions. Ideally it would be nice to remove the Type field from gl_shader altogether but currently it is used to differentiate between gl_shader and gl_shader_program in the ShaderObjects hash table. Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
* meta: Fix indentation in shader codeAnuj Phogat2016-06-021-2/+2
| | | | | Signed-off-by: Anuj Phogat <anuj.phogat@gmail.com> Acked-by: Matt Turner <mattst88@gmail.com>
* meta/blit: Don't blend integer values during MSAA resolvesJason Ekstrand2016-05-101-2/+11
| | | | Reviewed-by: Matt Turner <mattst88@gmail.com>
* mesa/meta: check for signed/unsigned int conversion for pbo getteximageDave Airlie2016-05-111-0/+3
| | | | | | | | | | | | | | | When doing GetTexSubImage using a PBO, we should check if it involves a signed/unsigned conversion and bail if it does, just like in the other cases. This fixes: GL33-CTS.gtf32.GL3Tests.packed_pixels.packed_pixels_pbo on Haswell at least. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=95324 Reviewed-by: Matt Turer <mattst88@gmail.com> Cc: mesa-stable@lists.freedesktop.org Signed-off-by: Dave Airlie <airlied@redhat.com>
* meta: Avoid random memory access on errorJuha-Pekka Heikkila2016-04-261-1/+1
| | | | | | | | | | Initialize drawFb to NULL in _mesa_meta_CopyImageSubData_uncompressed() if getting readFb fails uninitialized drawFb will cause randomness on cleanup. Signed-off-by: Juha-Pekka Heikkila <juhapekka.heikkila@gmail.com> Reviewed-by: Eduardo Lima Mitev <elima@igalia.com> Reviewed-by: Chad Versace <chad.versace@intel.com>
* meta: Don't botch color masks when changing drawbuffers.Kenneth Graunke2016-04-181-7/+75
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Color clears should respect each drawbuffer's color mask state. Previously, we tried to leave the color mask untouched. However, _mesa_meta_drawbuffers_from_bitfield() ended up rebinding all the color drawbuffers in a different order, so we ended up pairing drawbuffers with the wrong color mask state. The new _mesa_meta_drawbuffers_and_colormask() function does the same job as the old _mesa_meta_drawbuffers_from_bitfield(), but also rearranges the color mask state to match the new drawbuffer configuration. This code was largely ripped off from Gallium's st_Clear code. This fixes ES31-CTS.draw_buffers_indexed.color_masks, which binds up to 8 drawbuffers, sets color masks for each, and then calls glClearBufferfv to clear each buffer individually. ClearBuffer causes us to rebind only one drawbuffer, at which point we used ctx->Color.ColorMask[0] (draw buffer 0's state) for everything. We could probably delete _mesa_meta_drawbuffers_from_bitfield(), but I'd rather not think about the i965 fast clear code. Topi is rewriting a bunch of that soon anyway, so let's delete it then. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=94847 Signed-off-by: Kenneth Graunke <kenneth@whitecape.org> Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
* meta: Don't smash ColorMask when using MESA_META_COLOR_MASK save bit.Kenneth Graunke2016-04-182-5/+4
| | | | | | | | | | | This allows meta operations to inspect the existing color mask, and then do their own smashing. BlitFramebuffer and Clear already override the color mask, so this was also redundant. Signed-off-by: Kenneth Graunke <kenneth@whitecape.org> Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
* meta: use _mesa_prepare_mipmap_levels()Brian Paul2016-03-291-24/+8
| | | | | | | | | | | | | | | | | | | | | | | | The prepare_mipmap_level() wrapper for _mesa_prepare_mipmap_level() is not needed. It only served to undo the GL_TEXTURE_1D_ARRAY height/depth change was was made before the call to prepare_mipmap_level() Said another way, regardless of how the meta code manipulates the height/ depth dims for GL_TEXTURE_1D_ARRAY, the gl_texture_image dimensions are correctly set up by _mesa_prepare_mipmap_levels(). Tested by plugging _mesa_meta_GenerateMipmap() into the swrast driver and testing with piglit. v2 (idr): Early out of the mipmap generation loop with dstImage is NULL. This can occur for immutable textures that have a limited range of levels or in the presense of memory allocation failures. Fixes arb_texture_view-mipgen on Intel platforms. Reviewed-by: José Fonseca <jfonseca@vmware.com> Reviewed-by: Roland Scheidegger <sroland@vmware.com> Reviewed-by: Ian Romanick <ian.d.romanick@intel.com> Tested-by: Ian Romanick <ian.d.romanick@intel.com> Reviewed-by: Brian Paul <brianp@vmware.com>
* mesa: optionally associate a gl_program to ATI_fragment_shaderMiklós Máté2016-03-271-0/+3
| | | | | | | | | the state tracker will use it Acked-by: Brian Paul <brianp@vmware.com> Reviewed-by: Ian Romanick <ian.d.romanick@intel.com> Signed-off-by: Miklós Máté <mtmkls@gmail.com> Signed-off-by: Marek Olšák <marek.olsak@amd.com>
* meta: Make BlitFramebuffer() do sRGB encoding in ES 3.x.Kenneth Graunke2016-03-213-9/+43
| | | | | | | | | | | | | | | | | | | | | | | | | | According to the ES 3.0 and GL 4.4 specifications, glBlitFramebuffer is supposed to perform sRGB decoding and encoding whenever sRGB formats are in use. The ES 3.0 specification is completely clear, and has always stated this. However, the GL specification has changed behavior in 4.1, 4.2, and 4.4. The original behavior stated that no sRGB encoding should occur. The 4.4 behavior matches ES 3.0's wording. However, implementing the new behavior appears to break applications such as Left 4 Dead 2. This patch changes Meta to apply the ES 3.x rules in ES 3.x, but leaves OpenGL alone for now, to avoid breaking applications. Meta implements several other functions in terms of BlitFramebuffer, and many of those explicitly do not perform sRGB encoding. So, this patch explicitly disables sRGB encoding in those other functions, preserving the existing (correct) behavior. If you're from the future and are reading this, hi! Welcome to the "fun" of debugging sRGB problems! Best of luck! Signed-off-by: Kenneth Graunke <kenneth@whitecape.org> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
* meta: Don't use integer handles for shaders or programs.Kenneth Graunke2016-03-164-114/+91
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Previously, we gave our internal clear/blit shaders actual GL handles and stored them in the shader/program hash table. We used ordinary GL API entrypoints to work with them. We thought this shouldn't be a problem because GL doesn't allow applications to invent their own names for shaders or programs. GL allocates all names via glCreateShader and glCreateProgram. However, having them in the hash table is a bit risky: if a broken application guesses the name of our shaders or programs, it could alter them, potentially screwing up future meta operations. Also, test cases can observe the programs in the hash table. Running a single dEQP process that executes the following test list: dEQP-GLES3.functional.negative_api.buffer.clear dEQP-GLES3.functional.negative_api.shader.compile_shader dEQP-GLES3.functional.negative_api.shader.delete_shader would result in the last two tests breaking. The compile_shader test calls glCompileShader(9) straight away, and since it hasn't even created any shaders or programs, it expects to get a GL_INVALID_VALUE error because there's no such name. However, because the clear test ran first, it created Meta programs, so an object named "9" did exist. This patch reworks Meta to work with gl_shader and gl_shader_program pointers directly. These internal programs have bogus names, and are never stored in the hash tables, so they're invisible to applications. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=94485 Signed-off-by: Kenneth Graunke <kenneth@whitecape.org> Reviewed-by: Topi Pohjolainen <topi.pohjolainen@intel.com>
* meta: Use the _mesa_meta_compile_and_link_program helper more places.Kenneth Graunke2016-03-161-29/+5
| | | | | | | Less boilerplate. Signed-off-by: Kenneth Graunke <kenneth@whitecape.org> Reviewed-by: Topi Pohjolainen <topi.pohjolainen@intel.com>
* meta: Use ARB_explicit_attrib_location in the rest of the meta shaders.Kenneth Graunke2016-03-162-17/+15
| | | | | | | | | | | | | | | | | This is cleaner than using glBindAttribLocation(). Not all drivers support the extension, but I don't think those drivers use GLSL in the first place. Apparently some Meta shaders already use GL_ARB_explicit_attrib_location, so I think it should be okay. Honestly, I'm not sure how the old code worked anyway - we bound the attribute location for "texcoords", while all the shaders capitalized or spelled it differently. v2: Convert another instance in brw_meta_fast_clear.c. Signed-off-by: Kenneth Graunke <kenneth@whitecape.org> Reviewed-by: Matt Turner <mattst88@gmail.com>
* mesa: Completely remove QuerySamplesForFormat from driver func tableEduardo Lima Mitev2016-03-031-1/+0
| | | | | | | At this point, all uses have been replaced by the more general hook QueryInternalFormat, introduced by ARB_internalformat_query2. Reviewed-by: Dave Airlie <airlied@redhat.com>
* mesa: Add a default QueryInternalFormat() function for driversEduardo Lima Mitev2016-03-031-0/+1
| | | | | | | This is a fallback function for drivers not implementing ARB_internalformat_query2. Reviewed-by: Dave Airlie <airlied@redhat.com>
* meta: Remove the 'allocate_storage' parameter in _mesa_meta_pbo_GetTexSubImage()Anuj Phogat2016-03-022-5/+2
| | | | | | | | Texture is already allocated before calling this meta function. So, the value of 'allocate_storage' passed to the function is always false. Signed-off-by: Anuj Phogat <anuj.phogat@gmail.com> Reviewed-by: Topi Pohjolainen <topi.pohjolainen@intel.com>
* meta: Fix the pbo usage in meta for GLES{1,2} contextsAnuj Phogat2016-03-021-8/+13
| | | | | | | | | | | | | OpenGL ES 1.0 doesn't support using GL_STREAM_DRAW and both ES 1.0 and 2.0 don't support GL_STREAM_READ in glBufferData(). So, handle it correctly by calling the _mesa_meta_begin() before create_texture_for_pbo(). V2: Remove the changes related to allocate_storage. (Ian) Cc: <mesa-stable@lists.freedesktop.org> Signed-off-by: Anuj Phogat <anuj.phogat@gmail.com> Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
* meta: Don't pollute the framebuffer namespaceIan Romanick2016-03-014-54/+51
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 tests: - object-namespace-pollution glGetTexImage-compressed framebuffer - object-namespace-pollution glGenerateMipmap framebuffer Signed-off-by: Ian Romanick <ian.d.romanick@intel.com> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=92363 Reviewed-by: Topi Pohjolainen <topi.pohjolainen@intel.com>
* meta/decompress: Track framebuffer using gl_framebuffer instead of GL API ↵Ian Romanick2016-03-012-7/+12
| | | | | | | object handle Signed-off-by: Ian Romanick <ian.d.romanick@intel.com> Reviewed-by: Topi Pohjolainen <topi.pohjolainen@intel.com>
* meta/generate_mipmap: Track framebuffer using gl_framebuffer instead of GL ↵Ian Romanick2016-03-012-24/+16
| | | | | | | API object handle Signed-off-by: Ian Romanick <ian.d.romanick@intel.com> Reviewed-by: Topi Pohjolainen <topi.pohjolainen@intel.com>
* meta: Use _mesa_bind_framebuffers instead of _mesa_BindFramebufferIan Romanick2016-03-013-8/+40
| | | | | Signed-off-by: Ian Romanick <ian.d.romanick@intel.com> Reviewed-by: Topi Pohjolainen <topi.pohjolainen@intel.com>
* meta: Use _mesa_CreateFramebuffers instead of _mesa_GenFramebuffersIan Romanick2016-03-014-7/+7
| | | | | | | | | | | | | This enables later patches that will stop calling _mesa_GenFramebuffers or _mesa_CreateFramebuffers which pollute the framebuffer namespace. For framebuffers, the Bind call is still necessary. sed -i -e 's/_mesa_GenFramebuffers/_mesa_CreateFramebuffers/' \ src/mesa/drivers/common/*.c Signed-off-by: Ian Romanick <ian.d.romanick@intel.com> Reviewed-by: Topi Pohjolainen <topi.pohjolainen@intel.com>
* meta: Save and restore the framebuffer using gl_framebuffer instead of GL ↵Ian Romanick2016-03-012-8/+8
| | | | | | | | | | | | | | | | | | | | | | | | | API object handle Some meta operations can be called recursively. Future changes (the "Don't pollute the ... namespace" changes) will cause objects with invalid names to be used. If a nested meta operation tries to restore an object named 0xDEADBEEF, it will fail. This also fixes another latent bug in meta. In a multithreaded, multicontext application, one thread can delete an object that is bound in another thread. That object continues to exist until it is unbound (i.e., its refcount drops to zero). Meta unbinds objects all over the place. As a result, the rebind in _mesa_meta_end could fail because the object vanished! See https://bugs.freedesktop.org/show_bug.cgi?id=92363#c8. Using _mesa_reference_<object type> to save and restore the objects prevents the refcount from going to zero. Signed-off-by: Ian Romanick <ian.d.romanick@intel.com> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=92363 Reviewed-by: Topi Pohjolainen <topi.pohjolainen@intel.com>
* meta: Use _mesa_check_framebuffer_status instead of _mesa_CheckFramebufferStatusIan Romanick2016-03-014-12/+12
| | | | | | | | | | | | sed -i -e 's/_mesa_CheckFramebufferStatus(GL_DRAW_FRAMEBUFFER/_mesa_check_framebuffer_status(ctx, ctx->DrawBuffer/' \ -e 's/_mesa_CheckFramebufferStatus(GL_FRAMEBUFFER[^)]*/_mesa_check_framebuffer_status(ctx, ctx->DrawBuffer/' \ -e 's/_mesa_CheckFramebufferStatus(GL_READ_FRAMEBUFFER/_mesa_check_framebuffer_status(ctx, ctx->ReadBuffer/' \ $(grep -rl _mesa_CheckFramebufferStatus src/mesa/drivers) The second expression catches both GL_FRAMEBUFFER and GL_FRAMEBUFFER_EXT. Signed-off-by: Ian Romanick <ian.d.romanick@intel.com> Reviewed-by: Topi Pohjolainen <topi.pohjolainen@intel.com>
* meta: Obvious refactor of _mesa_meta_framebuffer_texture_imageIan Romanick2016-03-011-21/+5
| | | | | Signed-off-by: Ian Romanick <ian.d.romanick@intel.com> Reviewed-by: Topi Pohjolainen <topi.pohjolainen@intel.com>
* meta: Convert _mesa_meta_bind_fbo_image to take a gl_framebuffer instead of ↵Ian Romanick2016-03-015-49/+61
| | | | | | | | | | | | | | | | a GL API handle Also change the name of the function to _mesa_meta_framebuffer_texture_image. The function is basically a wrapper around _mesa_framebuffer_texture (which is used to implement glFramebufferTexture1D and friends), so it makes sense for it's name to be similar to that. The next patch will clean _mesa_meta_framebuffer_texture_image up considerably. Signed-off-by: Ian Romanick <ian.d.romanick@intel.com> Reviewed-by: Topi Pohjolainen <topi.pohjolainen@intel.com>
* meta/copy_image: use precomputed dst_internal_format to avoid segfaultIlia Mirkin2016-02-191-1/+1
| | | | | | | | | If the destination is a renderbuffer, dst_tex_image will be NULL. This fixes the *to_renderbuffer dEQP copy image tests. Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu> Reviewed-by: Jason Ekstrand <jason.ekstrand@intel.com> Cc: mesa-stable@lists.freedesktop.org
* 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>
* 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>
* meta: Use internal functions to set texture parametersIan Romanick2016-01-254-24/+49
| | | | | | | | | | | | | | | | | | | | | | _mesa_texture_parameteriv is used because (the more obvious) _mesa_texture_parameteri just stuffs the parameter in an array and calls _mesa_texture_parameteriv. This just cuts out the middleman. As a side bonus we no longer need check that ARB_stencil_texturing is supported. The test doesn't allow non-supporting implementations to avoid any work, and it's redundant with the value-changed test. Fix bug #93717 because the state restore commands at the bottom of _mesa_meta_GenerateMipmap no longer depend on the bound state. Fixes piglit arb_direct_state_access-generatetexturemipmap with the changes recently sent to the piglit mailing list. See the bugzilla entry for more info. Signed-off-by: Ian Romanick <ian.d.romanick@intel.com> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=93717 Cc: "11.0 11.1" <mesa-stable@lists.freedesktop.org> Reviewed-by: Jason Ekstrand <jason.ekstrand@intel.com>