summaryrefslogtreecommitdiffstats
path: root/src/mesa/drivers/common
Commit message (Collapse)AuthorAgeFilesLines
* glsl/main: remove unused params and make function staticTimothy Arceri2016-06-301-1/+1
| | | | Reviewed-by: Iago Toral Quiroga <[email protected]>
* 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 <[email protected]>
* 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 <[email protected]> Signed-off-by: Mathias Fröhlich <[email protected]>
* 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 <[email protected]>
* meta: Fix indentation in shader codeAnuj Phogat2016-06-021-2/+2
| | | | | Signed-off-by: Anuj Phogat <[email protected]> Acked-by: Matt Turner <[email protected]>
* meta/blit: Don't blend integer values during MSAA resolvesJason Ekstrand2016-05-101-2/+11
| | | | Reviewed-by: Matt Turner <[email protected]>
* 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 <[email protected]> Cc: [email protected] Signed-off-by: Dave Airlie <[email protected]>
* 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 <[email protected]> Reviewed-by: Eduardo Lima Mitev <[email protected]> Reviewed-by: Chad Versace <[email protected]>
* 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 <[email protected]> Reviewed-by: Jason Ekstrand <[email protected]>
* 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 <[email protected]> Reviewed-by: Jason Ekstrand <[email protected]>
* 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 <[email protected]> Reviewed-by: Roland Scheidegger <[email protected]> Reviewed-by: Ian Romanick <[email protected]> Tested-by: Ian Romanick <[email protected]> Reviewed-by: Brian Paul <[email protected]>
* 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 <[email protected]> Reviewed-by: Ian Romanick <[email protected]> Signed-off-by: Miklós Máté <[email protected]> Signed-off-by: Marek Olšák <[email protected]>
* 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 <[email protected]> Reviewed-by: Jordan Justen <[email protected]>
* 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 <[email protected]> Reviewed-by: Topi Pohjolainen <[email protected]>
* 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 <[email protected]> Reviewed-by: Topi Pohjolainen <[email protected]>
* 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 <[email protected]> Reviewed-by: Matt Turner <[email protected]>
* 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 <[email protected]>
* 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 <[email protected]>
* 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 <[email protected]> Reviewed-by: Topi Pohjolainen <[email protected]>
* 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: <[email protected]> Signed-off-by: Anuj Phogat <[email protected]> Reviewed-by: Ian Romanick <[email protected]>
* 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 <[email protected]> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=92363 Reviewed-by: Topi Pohjolainen <[email protected]>
* meta/decompress: Track framebuffer using gl_framebuffer instead of GL API ↵Ian Romanick2016-03-012-7/+12
| | | | | | | object handle Signed-off-by: Ian Romanick <[email protected]> Reviewed-by: Topi Pohjolainen <[email protected]>
* 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 <[email protected]> Reviewed-by: Topi Pohjolainen <[email protected]>
* meta: Use _mesa_bind_framebuffers instead of _mesa_BindFramebufferIan Romanick2016-03-013-8/+40
| | | | | Signed-off-by: Ian Romanick <[email protected]> Reviewed-by: Topi Pohjolainen <[email protected]>
* 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 <[email protected]> Reviewed-by: Topi Pohjolainen <[email protected]>
* 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 <[email protected]> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=92363 Reviewed-by: Topi Pohjolainen <[email protected]>
* 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 <[email protected]> Reviewed-by: Topi Pohjolainen <[email protected]>
* meta: Obvious refactor of _mesa_meta_framebuffer_texture_imageIan Romanick2016-03-011-21/+5
| | | | | Signed-off-by: Ian Romanick <[email protected]> Reviewed-by: Topi Pohjolainen <[email protected]>
* 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 <[email protected]> Reviewed-by: Topi Pohjolainen <[email protected]>
* 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 <[email protected]> Reviewed-by: Jason Ekstrand <[email protected]> Cc: [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]>
* 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]>
* 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 <[email protected]> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=93717 Cc: "11.0 11.1" <[email protected]> Reviewed-by: Jason Ekstrand <[email protected]>
* meta/blit: Restore GL_DEPTH_STENCIL_TEXTURE_MODE state for GL_TEXTURE_RECTANGLEIan Romanick2016-01-251-8/+8
| | | | | | | | | | | | | Commit c246828c added the code to save and restore the stencil texturing mode. The restore, however, was erroneously inside the 'target != GL_TEXTURE_RECTANGLE' block. Fixes piglit test 'arb_stencil_texturing-blit_corrupts_state GL_TEXTURE_RECTANGLE'. Signed-off-by: Ian Romanick <[email protected]> Cc: "11.0 11.1" <[email protected]> Reviewed-by: Jason Ekstrand <[email protected]>
* meta/copy_image: Fix typo in commentIan Romanick2016-01-251-1/+1
| | | | | | | Trivial. Signed-off-by: Ian Romanick <[email protected]> Reviewed-by: Jason Ekstrand <[email protected]>
* meta: remove const qualifier on _mesa_meta_fb_tex_blit_begin()Brian Paul2016-01-132-2/+2
| | | | | | To silence a compiler warning about a const/non-const mismatch. Reviewed-by: Ian Romanick <[email protected]>
* meta: Unconditionally set GL_SKIP_DECODE_EXTIan Romanick2016-01-112-11/+4
| | | | | | | | | | | | The path that depends on this will be avoided (by fallback_required) if the extension is not supported. _mesa_set_sampler_srgb_decode does not generate GL errors (by design), so there are no problems there. I kept this change separate and last because it is one of the few in the series that is not a candidate for the stable branch. Signed-off-by: Ian Romanick <[email protected]> Reviewed-by: Jason Ekstrand <[email protected]>
* meta: Only bind the sampler in one placeIan Romanick2016-01-112-8/+4
| | | | | | | | | | | All of the calls after the first _mesa_bind_sampler call are DSA style calls that don't depend on the current binding. I kept this change separate and last because it is one of the few in the series that is not a candidate for the stable branch. Signed-off-by: Ian Romanick <[email protected]> Reviewed-by: Jason Ekstrand <[email protected]>
* meta/decompress: Don't pollute the sampler object namespaceIan Romanick2016-01-111-7/+15
| | | | | | | | | | | | | | | | | | | | | | | | | | | 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: Jason Ekstrand <[email protected]>
* meta/decompress: Save and restore the sampler using gl_sampler_object ↵Ian Romanick2016-01-111-4/+5
| | | | | | | | | | | | instead of GL 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. Signed-off-by: Ian Romanick <[email protected]> Reviewed-by: Jason Ekstrand <[email protected]>
* meta/decompress: Track sampler using gl_sampler_object instead of GL API ↵Ian Romanick2016-01-112-12/+12
| | | | | | | object handle Signed-off-by: Ian Romanick <[email protected]> Reviewed-by: Jason Ekstrand <[email protected]>
* meta/decompress: Use internal functions for sampler object accessIan Romanick2016-01-111-4/+9
| | | | | Signed-off-by: Ian Romanick <[email protected]> Reviewed-by: Jason Ekstrand <[email protected]>
* meta/generate_mipmap: Don't pollute the sampler object namespaceIan Romanick2016-01-111-11/+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: Jason Ekstrand <[email protected]>
* meta/generate_mipmap: Save and restore the sampler using gl_sampler_object ↵Ian Romanick2016-01-111-4/+5
| | | | | | | | | | | | instead of GL 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. Signed-off-by: Ian Romanick <[email protected]> Reviewed-by: Jason Ekstrand <[email protected]>
* meta/generate_mipmap: Track sampler using gl_sampler_object instead of GL ↵Ian Romanick2016-01-112-14/+17
| | | | | | | API object handle Signed-off-by: Ian Romanick <[email protected]> Reviewed-by: Jason Ekstrand <[email protected]>
* meta/generate_mipmap: Use internal functions for sampler object accessIan Romanick2016-01-111-9/+11
| | | | | Signed-off-by: Ian Romanick <[email protected]> Reviewed-by: Jason Ekstrand <[email protected]>
* meta/blit: Don't pollute the sampler object namespace in ↵Ian Romanick2016-01-111-7/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | _mesa_meta_setup_sampler 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: Jason Ekstrand <[email protected]>
generated by cgit v1.2.3 (git 2.39.1) at 2024-12-24 18:23:50 +0000