summaryrefslogtreecommitdiffstats
path: root/src/mesa
Commit message (Collapse)AuthorAgeFilesLines
* mesa: rename GroupStackDepth to CurrentGroupEmil Velikov2015-12-031-16/+16
| | | | | | | | | The variable is used as the actual index, rather than the size of the group stack - rename it to reflect that. Suggested-by: Ilia Mirkin <[email protected]> Signed-off-by: Emil Velikov <[email protected]> Reviewed-by: Timothy Arceri <[email protected]>
* mesa: do not enable KHR_debug for ES 1.0Emil Velikov2015-12-031-1/+1
| | | | | | | | | | | | The extension requires (cough implements) GetPointervKHR (alias of GetPointerv) which in itself is available for ES 1.1 enabled mesa. Anyone willing to fish around and implement it for ES 1.0 is more than welcome to revert this commit. Until then lets restrict things. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=93048 Signed-off-by: Emil Velikov <[email protected]> Reviewed-by: Timothy Arceri <[email protected]>
* mesa/version: Update gl_extensions::Version during version overrideNanley Chery2015-12-031-0/+1
| | | | | | | | | | | Commit a16ffb743ced9fde80b2485dfc2d86ae74e86f25, which introduced gl_extensions::Version, updates the field when the context version is computed and when entering/exiting meta. Update this field when the version is overridden as well. Cc: "11.1" <[email protected]> Signed-off-by: Nanley Chery <[email protected]> Reviewed-by: Marta Lofstedt <[email protected]>
* mesa: print enum names rather than hexadecimal values in error messagesBrian Paul2015-12-031-6/+6
| | | | Trivial.
* st/mesa: add new st_copy_framebuffer_to_texture() functionBrian Paul2015-12-033-0/+178
| | | | | | | | | | | | This helper is used by the WGL state tracker to implement the wglBindTexImageARB() function. This is basically a new "meta" function. However, we're not putting it in the src/mesa/drivers/common/ directory because that code is not linked with gallium-based drivers. Reviewed-by: José Fonseca <[email protected]> Reviewed-by: Charmaine Lee <[email protected]>
* i965: use _Shader to get fragment program when updating surface stateTapani Pälli2015-12-031-2/+2
| | | | | | | | | | | | | Atomic counters and Images were using ctx::Shader that does not take in to account program pipeline changes, ctx::_Shader must be used for SSO to work. Commit c0347705 already changed ubo's to use this. Fixes failures seen with following Piglit test: arb_separate_shader_object-atomic-counter Signed-off-by: Tapani Pälli <[email protected]> Reviewed-by: Francisco Jerez <[email protected]> Cc: "11.0 11.1" <[email protected]>
* i965: Add INTEL_DEBUG=perf information for GS recompiles.Kenneth Graunke2015-12-021-0/+58
| | | | | | | Surprisingly, this didn't exist at all. Signed-off-by: Kenneth Graunke <[email protected]> Reviewed-by: Topi Pohjolainen <[email protected]>
* i965: De-duplicate key_debug() function.Kenneth Graunke2015-12-023-21/+10
| | | | | | | | | | | | This appeared in brw_vs.c and brw_wm.c, should have appeared in brw_gs.c, and was soon going to have to be in brw_tcs.c and brw_tes.c as well. So, instead, move it to a central location (which has to know about both struct brw_context and perf_debug()). Signed-off-by: Kenneth Graunke <[email protected]> Reviewed-by: Topi Pohjolainen <[email protected]>
* mesa: print enum string in compressed_subtexture_error_check() error msgBrian Paul2015-12-021-2/+2
| | | | Trivial.
* mesa: fix VIEWPORT_INDEX_PROVOKING_VERTEX and LAYER_PROVOKING_VERTEX queriesRoland Scheidegger2015-12-023-2/+8
| | | | | | | | | | | | | These are implementation-dependent queries, but so far we just returned the value of whatever the current provoking vertex convention was set to, which was clearly wrong. Just make this a variable in the context constants like for other things which are implementation dependent (I assume all drivers will want to set this to the same value for both queries), and set it to GL_UNDEFINED_VERTEX which is correct for everybody (and drivers can override it). Reviewed-by: Brian Paul <[email protected]> CC: <[email protected]>
* Remove Sun CC specific code.Jose Fonseca2015-12-021-14/+0
| | | | | Reviewed-by: Matt Turner <[email protected]> Acked-by: Alan Coopersmith <[email protected]>
* i965: Increase BRW_MAX_UBO to 14.Kenneth Graunke2015-12-011-1/+1
| | | | | | | | | | | | | | | | | | | | | The NVIDIA binary driver and Intel's closed source driver both expose 14 here, rather than the GL minimum of 12. Let's follow suit. Without this, Shadow of Mordor fails to render correctly and triggers OpenGL errors: Mesa: User error: GL_INVALID_VALUE in glBindBufferBase(index=68) Mesa: User error: GL_INVALID_VALUE in glUniformBlockBinding(block binding 68 >= 60) There are 5 stages (VS, TCS, TES, GS, FS), and 12 * 5 = 60 is too small. 14 * 5 = 70 will work just fine. Tapani believes this will also help Alien Isolation. Signed-off-by: Kenneth Graunke <[email protected]> Reviewed-by: Jordan Justen <[email protected]> Acked-by: Tapani Pälli <[email protected]> Acked-by: Matt Turner <[email protected]>
* i965: Do dead-code elimination in a single pass.Matt Turner2015-12-013-29/+16
| | | | | | | | | | | | The first pass marked dead instructions as opcode = NOP, and a second pass deleted those instructions so that the live ranges used in the first pass wouldn't change. But since we're walking the instructions in reverse order, we can just do everything in one pass. The only thing we have to do is walk the blocks in reverse as well. Reviewed-by: Francisco Jerez <[email protected]>
* i965: Don't mark dead instructions' sources live.Matt Turner2015-12-012-0/+8
| | | | | | | Removes dead code from glsl-mat-from-int-ctor-03.shader_test. Reported-by: Juan A. Suarez Romero <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]>
* mapi: Fix enums.c build with other build systems.Eric Anholt2015-12-011-1/+1
| | | | | Tested with scons (by both myself and Mark Janes), Android is just copy and paste.
* mesa: Drop the blacklisting of new GL enums.Eric Anholt2015-12-011-3/+2
| | | | | | | | | | | | | Now when people need new extensions, they can skip the entire enum-definition process, and we can stop reviewing new extension XML for its enum content. This also brings in a new enum that I wanted to use in enum_strings.cpp for testing the code generator. v2: Drop comment about disabled GL_1PASS_EXT test. Reviewed-by: Ian Romanick <[email protected]>
* mesa: Drop bitfield "enums" from the enum-to-string table.Eric Anholt2015-12-011-13/+12
| | | | | | | | | | | | | | Asking the table for bitfield names doesn't make any sense. For 0x10, do you want GL_GLYPH_HORIZONTAL_BEARING_ADVANCE_BIT_NV or GL_COLOR_BUFFER_BIT4_QCOM or GL_POLYGON_STIPPLE_BIT or GL_SHADER_GLOBAL_ACCESS_BARRIER_BIT_NV? Giving a useful answer would depend on a whole lot of context. This also fixes a bad enum table entry, where we chose GL_HINT_BIT instead of GL_ABGR_EXT for 0x8000, so we can now fix its entry in the enum_strings test. Reviewed-by: Ian Romanick <[email protected]>
* mesa: Drop apparently typoed GL_ALL_CLIENT_ATTRIB_BITS.Eric Anholt2015-12-011-3/+1
| | | | | | | | GL_ALL_ATTRIB_BITS is a thing, and GL_CLIENT_ALL_ATTRIB_BITS, but I don't see GL_ALL_CLIENT_ATTRIB_BITS in my grepping of khronos XML, GL extension specs, GL 1.1, GL 2.2, and GL 4.4. Reviewed-by: Brian Paul <[email protected]>
* mesa: Cut enum_strings.cpp test down to a few hand-chosen enums.Eric Anholt2015-12-011-1822/+36
| | | | | | | | | | | | | | | | The previous contents appeared to be the output of some form of code generation for all enums, with a few entries hand-edited to deal with oddness. The downside to this was that when an enum gets promoted from vendor to _EXT or _EXT to _ARB or _ARB to core, make check starts failing even when the commiter has done nothing wrong. Instead of black-box testing the code generation, pick a few enums that intentionally poke the interesting cases of code generation. People editing the code generator should be diffing the generated code anyway. This should catch when they fail to do so, without throwing false negatives when people update the GL XML. Reviewed-by: Ian Romanick <[email protected]>
* automake: fix some occurrences of hardcoded -ldl and -lpthreadJonathan Gray2015-12-011-1/+2
| | | | | | | | | Correct some occurrences of -ldl and -lpthread to use $(DLOPEN_LIBS) and $(PTHREAD_LIBS) respectively. Signed-off-by: Jonathan Gray <[email protected]> Cc: "11.0 11.1" <[email protected]> Reviewed-by: Emil Velikov <[email protected]>
* i965/fs: remove unused fs_reg offsetSamuel Iglesias Gonsálvez2015-11-301-1/+0
| | | | | Signed-off-by: Samuel Iglesias Gonsálvez <[email protected]> Reviewed-by: Abdiel Janulgue <[email protected]>
* i965: Add src/dst interference for certain instructions with hazards.Kenneth Graunke2015-11-307-35/+123
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When working on tessellation shaders, I created some vec4 virtual opcodes for creating message headers through a sequence like: mov(8) g7<1>UD 0x00000000UD { align1 WE_all 1Q compacted }; mov(1) g7.5<1>UD 0x00000100UD { align1 WE_all }; mov(1) g7<1>UD g0<0,1,0>UD { align1 WE_all compacted }; mov(1) g7.3<1>UD g8<0,1,0>UD { align1 WE_all }; This is done in the generator since the vec4 backend can't handle align1 regioning. From the visitor's point of view, this is a single opcode: hs_set_output_urb_offsets vgrf7.0:UD, 1U, vgrf8.xxxx:UD Normally, there's no hazard between sources and destinations - an instruction (naturally) reads its sources, then writes the result to the destination. However, when the virtual instruction generates multiple hardware instructions, we can get into trouble. In the above example, if the register allocator assigned vgrf7 and vgrf8 to the same hardware register, then we'd clobber the source with 0 in the first instruction, and read back the wrong value in the last one. It occured to me that this is exactly the same problem we have with SIMD16 instructions that use W/UW or B/UB types with 0 stride. The hardware implicitly decodes them as two SIMD8 instructions, and with the overlapping regions, the first would clobber the second. Previously, we handled that by incrementing the live range end IP by 1, which works, but is excessive: the next instruction doesn't actually care about that. It might also be the end of control flow. This might keep values alive too long. What we really want is to say "my source and destinations interfere". This patch creates new infrastructure for doing just that, and teaches the register allocator to add interference when there's a hazard. For my vec4 case, we can determine this by switching on opcodes. For the SIMD16 case, we just move the existing code there. I audited our existing virtual opcodes that generate multiple instructions; I believe FS_OPCODE_PACK_HALF_2x16_SPLIT needs this treatment as well, but no others. v2: Rebased by mattst88. Signed-off-by: Kenneth Graunke <[email protected]> Reviewed-by: Matt Turner <[email protected]>
* i965: Fix JIP to properly skip over unrelated control flow.Kenneth Graunke2015-11-301-1/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We've apparently always been botching JIP for sequences such as: do cmp.f0.0 ... (+f0.0) break ... if ... else ... endif ... while Normally, UIP is supposed to point to the final destination of the jump, while in nested control flow, JIP is supposed to point to the end of the current nesting level. It essentially bounces out of the current nested control flow, to an instruction that has a JIP which bounces out another level, and so on. In the above example, when setting JIP for the BREAK, we call brw_find_next_block_end(), which begins a search after the BREAK for the next ENDIF, ELSE, WHILE, or HALT. It ignores the IF and finds the ELSE, setting JIP there. This makes no sense at all. The break is supposed to skip over the whole if/else/endif block entirely. They have a sibling relationship, not a nesting relationship. This patch fixes brw_find_next_block_end() to track depth as it does its search, and ignore anything not at depth 0. So when it sees the IF, it ignores everything until after the ENDIF. That way, it finds the end of the right block. I noticed this while reading some assembly code. We believe jumping earlier is harmless, but makes the EU walk through a bunch of disabled instructions for no reason. I noticed that GLBenchmark Manhattan had a shader that contained a BREAK with a bogus JIP, but didn't measure any performance improvement (it's likely miniscule, if there is any). Signed-off-by: Kenneth Graunke <[email protected]> Reviewed-by: Matt Turner <[email protected]> Reviewed-by: Francisco Jerez <[email protected]>
* mesa: remove len argument from _mesa_shader_debug()Emil Velikov2015-11-292-7/+6
| | | | | | | | | | There was only a single user which was using strlen(buf). As this function is not user facing (i.e. we don't need to feed back original length via a callback), we can simplify things. Suggested-by: Timothy Arceri <[email protected]> Signed-off-by: Emil Velikov <[email protected]> Reviewed-by: Timothy Arceri <[email protected]>
* drivers/x11: scons: partially revert b9b40ef9b76Emil Velikov2015-11-291-2/+0
| | | | | | | | | | As glsl_types.{cpp,h} were moved out of the sconscript (commit b23a4859f4d "scons: Build nir/glsl_types.cpp once.") remove the dangling includes. Cc: Jose Fonseca <[email protected]> Signed-off-by: Emil Velikov <[email protected]> Reviewed-by: Jose Fonseca <[email protected]>
* mesa/program: remove dead function declarationsEmil Velikov2015-11-292-5/+0
| | | | | | | | | | | | Dead since 5e9aa9926b9 (2011) - _mesa_ir_compile_shader 69e07bdeb42 (2009) - _mesa_get_program_register Cc: Kenneth Graunke <[email protected]> Cc: Brian Paul <[email protected]> Signed-off-by: Emil Velikov <[email protected]> Reviewed-by: Matt Turner <[email protected]>
* mesa: support GL_RED/GL_RG in ES2 contexts when driver support existsIlia Mirkin2015-11-284-4/+11
| | | | | | | Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=93126 Signed-off-by: Ilia Mirkin <[email protected]> Reviewed-by: Eduardo Lima Mitev <[email protected]> Cc: "11.0 11.1" <[email protected]>
* glsl: don't generate extra errors in ValidateProgramPipelineTimothy Arceri2015-11-271-2/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | From Section 11.1.3.11 (Validation) of the GLES 3.1 spec: "An INVALID_OPERATION error is generated by any command that trans- fers vertices to the GL or launches compute work if the current set of active program objects cannot be executed, for reasons including:" It then goes on to list the rules we validate in the _mesa_validate_program_pipeline() function. For ValidateProgramPipeline the only mention of generating an error is: "An INVALID_OPERATION error is generated if pipeline is not a name re- turned from a previous call to GenProgramPipelines or if such a name has since been deleted by DeleteProgramPipelines," Which we handle separately. This fixes: ES31-CTS.sepshaderobjs.PipelineApi No regressions on the eEQP 3.1 tests. Cc: Gregory Hainaut <[email protected]> Reviewed-by: Tapani Pälli <[email protected]>
* i965/gen9+: Switch thread scratch space to non-coherent stateless access.Francisco Jerez2015-11-263-4/+19
| | | | | | | | | | | | | | | | | | | | The thread scratch space is thread-local so using the full IA-coherent stateless surface index (255 since Gen8) is unnecessary and potentially expensive. On Gen8 and early steppings of Gen9 this is not a functional change because the kernel already sets bit 4 of HDC_CHICKEN0 which overrides all HDC memory access to be non-coherent in order to workaround a hardware bug. This happens to fix a full system hang when running any spilling code on a pre-production SKL GT4e machine I have on my desk (forcing all HDC access to non-coherent from the kernel up to stepping F0 might be a good idea though regardless of this patch), and improves performance of the OglPSBump2 SynMark benchmark run with INTEL_DEBUG=spill_fs by 33% (11 runs, 5% significance) on a production SKL GT2 (on which HDC IA-coherency is apparently functional so it wouldn't make sense to disable globally). Reviewed-by: Kristian Høgsberg <[email protected]>
* i965/fs: Don't use Gen7-style scratch block reads on Gen9+.Francisco Jerez2015-11-261-2/+9
| | | | | | | | | | | | | Unfortunately Gen7 scratch block reads and writes seem to be hardwired to BTI 255 even on Gen9+ where that index causes the dataport to do an IA-coherent read or write. This change is required for the next patch to be correct, since otherwise we would be writing to the scratch space using non-coherent access and then reading it back using IA-coherent reads, which wouldn't be guaranteed to return the value previously written to the same location without introducing an additional HDC flush in between. Reviewed-by: Kristian Høgsberg <[email protected]>
* i965: Add symbolic defines for some magic dataport surface indices.Francisco Jerez2015-11-261-0/+13
| | | | Reviewed-by: Kristian Høgsberg <[email protected]>
* mesa: remove ARB_geometry_shader4Marta Lofstedt2015-11-268-82/+8
| | | | | | | | | | No drivers currently implement ARB_geometry_shader4, nor are there any plans to implement it. We only support the version of geometry shaders that was incorporated into OpenGL 3.2 / GLSL 1.50. Signed-off-by: Marta Lofstedt <[email protected]> Reviewed-by: Ilia Mirkin <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]>
* mesa: error out in indirect draw when vertex bindings mismatchTapani Pälli2015-11-263-0/+27
| | | | | | | | | | | | | | | | | | | | Patch adds additional mask for tracking which vertex arrays have associated vertex buffer binding set. This array can be directly compared to which vertex arrays are enabled and should match when drawing. Fixes following CTS tests: ES31-CTS.draw_indirect.negative-noVBO-arrays ES31-CTS.draw_indirect.negative-noVBO-elements v2: update mask in vertex_array_attrib_binding v3: rename mask and make it track _BoundArrays which matches what was actually originally wanted (Fredrik Höglund) v4: code cleanup, check for GLES 3.1 (Fredrik Höglund) Signed-off-by: Tapani Pälli <[email protected]> Reviewed-by: Fredrik Höglund <[email protected]>
* i965: Fix scalar vertex shader struct outputs.Kenneth Graunke2015-11-252-8/+34
| | | | | | | | | | | | | | | | | | | | While we correctly set output[] for composite varyings, we set completely bogus values for output_components[], making emit_urb_writes() output zeros instead of the actual values. Unfortunately, our simple approach goes out the window, and we need to recurse into structs to get the proper value of vector_elements for each field. Together with the previous patch, this fixes rendering in an upcoming game from Feral Interactive. v2: Use pointers instead of pass-by-mutable-reference (Jason, Matt). Cc: "11.1 11.0" <[email protected]> Signed-off-by: Kenneth Graunke <[email protected]> Reviewed-by: Jason Ekstrand <[email protected]> Reviewed-by: Matt Turner <[email protected]>
* i965: Fix fragment shader struct inputs.Kenneth Graunke2015-11-253-82/+84
| | | | | | | | | | | | | | | | | | | | | | | | | Apparently we have literally no support for FS varying struct inputs. This is somewhat surprising, given that we've had tests for that very feature that have been passing for a long time. Normally, varying packing splits up structures for us, so we don't see them in the backend. However, with SSO, varying packing isn't around to save us, and we get actual structs that we have to handle. This patch changes fs_visitor::emit_general_interpolation() to work recursively, properly handling nested structs/arrays/and so on. (It's easier to read with diff -b, as indentation changes.) When using the vec4 VS backend, this fixes rendering in an upcoming game from Feral Interactive. (The scalar VS backend requires additional bug fixes in the next patch.) v2: Use pointers instead of pass-by-mutable-reference (Jason, Matt). Cc: "11.1 11.0" <[email protected]> Signed-off-by: Kenneth Graunke <[email protected]> Reviewed-by: Jason Ekstrand <[email protected]> Reviewed-by: Matt Turner <[email protected]>
* st/mesa: remove outdated commentNicolai Hähnle2015-11-251-2/+0
| | | | | | | | | | | | | | The enable of AMD_performance_monitor is no longer related to whether queries are run by the GPU since the commit mentioned below. Suggested-by: Samuel Pitoiset <[email protected]> Reviewed-by: Samuel Pitoiset <[email protected]> commit ddf27a3dd062c78ff49a69a1396be4de9c1b5d37 Author: Nicolai Hähnle <[email protected]> Date: Tue Nov 10 13:35:01 2015 +0100 gallium: remove pipe_driver_query_group_info field type
* st/mesa: delay initialization of performance countersNicolai Hähnle2015-11-253-13/+19
| | | | Reviewed-by: Samuel Pitoiset <[email protected]>
* mesa/main: allow delayed initialization of performance monitorsNicolai Hähnle2015-11-252-4/+36
| | | | | | | | | | | | | | | | Most applications never use performance counters, so allow drivers to skip potentially expensive initialization steps. A driver that wants to use this must enable the appropriate extension(s) at context initialization and set the InitPerfMonitorGroups driver function which will be called the first time information about the performance monitor groups is actually used. The init_groups helper is called for API functions that can be called before a monitor object exists. Functions that require an existing monitor object can rely on init_groups having been called before. Reviewed-by: Samuel Pitoiset <[email protected]>
* i965: remove trailing spaces in various filesIago Toral Quiroga2015-11-2511-34/+29
| | | | Acked-by: Kenneth Graunke <[email protected]>
* i965: Pass brw_context pointer, not gl_context pointer.Matt Turner2015-11-241-2/+1
| | | | Fixes a warning introduced by commit dcadd855.
* mesa: Use unreachable() instead of a default case.Matt Turner2015-11-241-5/+5
| | | | (And add an unreachable() in one place that didn't have a default case)
* meta: Don't save or restore the active client textureIan Romanick2015-11-242-4/+0
| | | | | | | | | This setting is only used by glTexCoordPointer and related glEnable calls. Since the preceeding commits removed all of those, it is not necessary to save, reset to default, or restore this state. Signed-off-by: Ian Romanick <[email protected]> Reviewed-by: Anuj Phogat <[email protected]>
* meta: Don't save or restore the VBO bindingIan Romanick2015-11-242-7/+0
| | | | | | | | Nothing left in meta does anything with the VBO binding, so we don't need to save or restore it. The VAO binding is still modified. Signed-off-by: Ian Romanick <[email protected]> Reviewed-by: Anuj Phogat <[email protected]>
* meta/TexSubImage: Don't pollute the buffer object namespaceIan Romanick2015-11-241-18/+24
| | | | | | | | | | | | | | | | | | | | | | | | | | | 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]>
* meta: Don't pollute the buffer object namespace in _mesa_meta_DrawTexIan Romanick2015-11-244-38/+29
| | | | | | | | | | | | | | | | | | | | | | | | | | | 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]>
* meta: Use internal functions for buffer object and VAO access in ↵Ian Romanick2015-11-241-12/+20
| | | | | | | _mesa_meta_DrawTex Signed-off-by: Ian Romanick <[email protected]> Reviewed-by: Anuj Phogat <[email protected]>
* meta: Track VBO using gl_buffer_object instead of GL API object handle in ↵Ian Romanick2015-11-242-6/+19
| | | | | | | _mesa_meta_DrawTex Signed-off-by: Ian Romanick <[email protected]> Reviewed-by: Anuj Phogat <[email protected]>
* meta: Partially convert _mesa_meta_DrawTex to DSAIan Romanick2015-11-241-6/+6
| | | | | Signed-off-by: Ian Romanick <[email protected]> Reviewed-by: Anuj Phogat <[email protected]>
* meta: Don't pollute the buffer object namespace in ↵Ian Romanick2015-11-241-14/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | _mesa_meta_setup_vertex_objects 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]>
* meta: Use internal functions for buffer object and VAO accessIan Romanick2015-11-241-33/+43
| | | | | Signed-off-by: Ian Romanick <[email protected]> Reviewed-by: Anuj Phogat <[email protected]>
generated by cgit v1.2.3 (git 2.39.1) at 2024-12-28 16:43:06 +0000