summaryrefslogtreecommitdiffstats
path: root/src
Commit message (Collapse)AuthorAgeFilesLines
* radeonsi: implement OpenGL edge flagsMarek Olšák2013-12-033-6/+48
| | | | Reviewed-by: Michel Dänzer <[email protected]>
* st/mesa: add support for layered framebuffers and consolidate codeMarek Olšák2013-12-036-93/+99
| | | | | | | | | This is a subset of geometry shaders. It's all about setting first_layer and last_layer correctly. Also some code between st_render_texture and update_framebuffer_state is consolidated. It doesn't use rtt_level and derives the level from dimensions instead as the code in st_atom_framebuffer.c did.
* mesa: expose AMD_vertex_shader_layer in the core profile onlyMarek Olšák2013-12-031-1/+1
| | | | | | | It needs glFramebufferTexture, which isn't available in the compatibility profile. Reviewed-by: Ian Romanick <[email protected]>
* egl: add HAVE_LIBDRM define, fix EGL X11 platformTapani Pälli2013-12-031-6/+3
| | | | | | | | | | | | | | | | | | | | Commit a594cec broke EGL X11 backend by adding dependency between X11 and DRM backends requiring HAVE_EGL_PLATFORM_DRM defined for X11. This patch fixes the issue by adding additional define for libdrm detection independent of which backend is being compiled. Tested by compiling Mesa with '--with-egl-platforms=x11' and running es2gears_x11 + glbenchmark2.7 successfully. v2: return true for dri2_auth if running without libdrm (Samuel) v3: check libdrm when building EGL drm platform + AM_CFLAGS fix (Emil) Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=72062 Signed-off-by: Tapani Pälli <[email protected]> Reviewed-by: Emil Velikov <[email protected]> Reviewed-by: Chad Versace <[email protected]> Cc: Samuel Thibault <[email protected]> Cc: [email protected]
* freedreno: Add a few texture formatsAndreas Heider2013-12-021-0/+3
|
* i965: Skip the register write check on Broadwell.Kenneth Graunke2013-12-021-1/+5
| | | | | | | | | MI_STORE_REGISTER_MEM has to take a 48-bit address, so the existing code doesn't work. But supposedly Broadwell has a register whitelist and just works out of the box anyway, so there's no need to check. Signed-off-by: Kenneth Graunke <[email protected]> Reviewed-by: Eric Anholt <[email protected]>
* i965: Fix texture border color on Broadwell.Kenneth Graunke2013-12-021-1/+11
| | | | | | | | | | | | The Gen7 sampler state code still works. Increasing the alignment to 64 bytes makes bit 5 zero, which is good because it's now reserved. Since we don't use the new filter bits, we can leave those as zero too, which means we don't need to update the code to update the pointer. (We probably should anyway, for clarity, but alas, another day.) Signed-off-by: Kenneth Graunke <[email protected]> Reviewed-by: Eric Anholt <[email protected]>
* i965: Don't use MACH for integer multiplies on Gen8+.Kenneth Graunke2013-12-022-2/+2
| | | | | | | | | | | The documentation is really hard to follow, but apparently a 32-bit x 32-bit multiply just works without the MACH macro. The macro apparently is only necessary to get the full 64-bit value. Fixes Piglit tests [vf]s-op-mult-int-int.shader_test. Signed-off-by: Kenneth Graunke <[email protected]> Reviewed-by: Eric Anholt <[email protected]>
* i965: Fix texture swizzling on Broadwell.Kenneth Graunke2013-12-021-1/+1
| | | | | | | | Like Haswell, we do this in SURFACE_STATE rather than shader workarounds. Signed-off-by: Kenneth Graunke <[email protected]> Reviewed-by: Eric Anholt <[email protected]>
* i965: Set vertical alignment unit to 4 on Broadwell.Kenneth Graunke2013-12-021-0/+6
| | | | | | | | | | | | Broadwell doesn't support a surface vertical alignment of 2. It only supports VALIGN_4, VALIGN_8, or VALIGN_16. I chose 4 since it's the least wasteful. v2: Replace my comment with a better one from Eric. Move Broadwell checks earlier so it's more obvious that "return 2" won't be hit. Signed-off-by: Kenneth Graunke <[email protected]> Reviewed-by: Eric Anholt <[email protected]>
* i965/vs: Always store pull constant offsets in GRFs on Gen8.Kenneth Graunke2013-12-021-1/+15
| | | | | | | | | | | | We need to SEND from a GRF, and we can only obtain those prior to register allocation. This allows us to do pull constant loads without the MRF hack. v2: Reword comments (suggested by Paul). Signed-off-by: Kenneth Graunke <[email protected]> Reviewed-by: Paul Berry <[email protected]>
* i965/vs: Don't copy propagate into SEND-from-GRF messages.Kenneth Graunke2013-12-021-0/+3
| | | | | | | | SEND can't deal with swizzles, source modifiers, and so on. This should avoid problems with VS pull constant loads on Broadwell. Signed-off-by: Kenneth Graunke <[email protected]> Reviewed-by: Eric Anholt <[email protected]>
* clover: Fix missing minus sign in 'iterator_adaptor::operator-='.Francisco Jerez2013-12-021-1/+1
| | | | | The method is currently unused, this probably doesn't fix anything at this point.
* i965/hsw: Apply non-msrt fast color clear w/a to all HSW GTsChad Versace2013-12-021-6/+12
| | | | | | | | | | | | | | | | | | | | | | Pre-patch, the workaround was applied to only HSW GT3. However, the workaround also fixes render corruption on the HSW GT1 Chromebook, codenamed Falco. Also, update the BSpec quote that discusses the workaround to reflect the latest BSpec. The BSpec states that the workaround is required for Ivybridge and Baytrail as well as Haswell. But, we apply the workaround to only Haswell because (a) we suspect that is the only hardware where it is actually required and (b) we haven't yet validated the workaround for the other hardware. CC: "9.2, 10.0" <[email protected]> CC: Anuj Phogat <[email protected]> OTC-Tracker: CHRMOS-812 Reviewed-by: Paul Berry <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]> Signed-off-by: Chad Versace <[email protected]>
* glsl: Simplify the built-in function linking code.Kenneth Graunke2013-12-017-36/+31
| | | | | | | | | | | | | | | | | | Previously, we stored an array of up to 16 additional shaders to link, as well as a count of how many each shader actually needed. Since the built-in functions rewrite, all the built-ins are stored in a single shader. So all we need is a boolean indicating whether a shader needs to link against built-ins or not. During linking, we can avoid creating the temporary array if none of the shaders being linked need built-ins. Otherwise, it's simply a copy of the array that has one additional element. This is much simpler. This patch saves approximately 128 bytes of memory per gl_shader object. Signed-off-by: Kenneth Graunke <[email protected]> Reviewed-by: Ian Romanick <[email protected]>
* glsl: Create an accessor for the built-in function shader.Kenneth Graunke2013-12-012-2/+13
| | | | | Signed-off-by: Kenneth Graunke <[email protected]> Reviewed-by: Ian Romanick <[email protected]>
* glsl: Drop crazy looping from no_matching_function_error().Kenneth Graunke2013-12-011-16/+23
| | | | | | | | | | | | Since the built-in functions rewrite, num_builtins_to_link is always either 0 or 1, so we don't need tho crazy loop starting at -1 with a special case. All we need to do is print the prototypes from the current shader, and the single built-in function shader (if present). Signed-off-by: Kenneth Graunke <[email protected]> Reviewed-by: Ian Romanick <[email protected]>
* glsl: Merge "candidates are: " message to the previous line.Kenneth Graunke2013-12-011-6/+4
| | | | | | | | | | | | | | | | | | | | | | | | | Previously, when we hit a "no matching function" error, it looked like: 0:0(0): error: no matching function for call to `cos()' 0:0(0): error: candidates are: float cos(float) 0:0(0): error: vec2 cos(vec2) 0:0(0): error: vec3 cos(vec3) 0:0(0): error: vec4 cos(vec4) Now it looks like: 0:0(0): error: no matching function for call to `cos()'; candidates are: 0:0(0): error: float cos(float) 0:0(0): error: vec2 cos(vec2) 0:0(0): error: vec3 cos(vec3) 0:0(0): error: vec4 cos(vec4) This is not really any worse and removes the need for the prefix variable. It will also help with the next commit's refactoring. Signed-off-by: Kenneth Graunke <[email protected]> Reviewed-by: Chris Forbes <[email protected]> Reviewed-by: Ian Romanick <[email protected]>
* glsl: Drop unused call_ir parameter from generate_call().Kenneth Graunke2013-12-011-8/+6
| | | | | Signed-off-by: Kenneth Graunke <[email protected]> Reviewed-by: Ian Romanick <[email protected]>
* glsl: Remove useless iteration through function parameters.Kenneth Graunke2013-12-011-6/+0
| | | | | | | | | There's no need to loop through the "parameters" list and remove every element; move_nodes_to(&parameters) already throws away all elements of the destination list. Signed-off-by: Kenneth Graunke <[email protected]> Reviewed-by: Ian Romanick <[email protected]>
* Fix 'make check' in src/mapi/glapi/tests when builddir != srcdirJon TURNEY2013-12-011-0/+1
| | | | | | | | | | make[5]: Entering directory `/jhbuild/build/mesa/mesa/src/mapi/glapi/tests' CXX check_table.o /jhbuild/checkout/mesa/mesa/src/mapi/glapi/tests/check_table.cpp:29:30: fatal error: glapi/glapitable.h: No such file or directory We should look for the generated file glapi/glapitable.h in builddir, not srcdir Signed-off-by: Jon TURNEY <[email protected]>
* i965/gen6: Fix multisample resolve blits for luminance/intensity 32F formats.Paul Berry2013-11-291-0/+15
| | | | | | | | | | | | | | | | | | | | | | | | | On gen6, multisamble resolve blits use the SAMPLE message to blend together the 4 samples for each texel. For some reason, SAMPLE doesn't blend together the proper samples when the source format is L32_FLOAT or I32_FLOAT, resulting in blocky artifacts. To work around this problem, sample from the source surface using R32_FLOAT. This shouldn't affect rendering correctness, because when doing these resolve blits, the destination format is R32_FLOAT, so the channel replication done by L32_FLOAT and I32_FLOAT is unnecessary. Fixes piglit tests on Sandy Bridge: - spec/ARB_texture_float/multisample-formats 2 GL_ARB_texture_float - spec/ARB_texture_float/multisample-formats 4 GL_ARB_texture_float No piglit regressions on Sandy Bridge. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=70601 Cc: Kenneth Graunke <[email protected]> Cc: [email protected] Reviewed-by: Kenneth Graunke <[email protected]>
* glsl: Remove unused field loop_variable_state::loop.Paul Berry2013-11-291-5/+0
| | | | | | This field was neither initialized nor used. It was just dead memory. Reviewed-by: Kenneth Graunke <[email protected]>
* glsl: Improve documentation of ir_loop counter/control fields.Paul Berry2013-11-291-6/+28
| | | | | Reviewed-by: Eric Anholt <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]>
* glsl: In ir_validate, check that ir_loop::counter always refers to a new var.Paul Berry2013-11-291-0/+13
| | | | | | | | | | | | | The compiler back-ends (i965's fs_visitor and brw_visitor, ir_to_mesa_visitor, and glsl_to_tgsi_visitor) have been assuming this for some time. Thanks to the preceding patch, the compiler front-end no longer breaks this assumption. This patch adds code to validate the assumption so that if we have future bugs, we'll be able to catch them earlier. Reviewed-by: Eric Anholt <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]>
* glsl: Fix inconsistent assumptions about ir_loop::counter.Paul Berry2013-11-293-2/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The compiler back-ends (i965's fs_visitor and brw_visitor, ir_to_mesa_visitor, and glsl_to_tgsi_visitor) assume that when ir_loop::counter is non-null, it points to a fresh ir_variable that should be used as the loop counter (as opposed to an ir_variable that exists elsewhere in the instruction stream). However, previous to this patch: (1) loop_control_visitor did not create a new variable for ir_loop::counter; instead it re-used the existing ir_variable. This caused the loop counter to be double-incremented (once explicitly by the body of the loop, and once implicitly by ir_loop::increment). (2) ir_clone did not clone ir_loop::counter properly, resulting in the cloned ir_loop pointing to the source ir_loop's counter. (3) ir_hierarchical_visitor did not visit ir_loop::counter, resulting in the ir_variable being missed by reparenting. Additionally, most optimization passes (e.g. loop unrolling) assume that the variable mentioned by ir_loop::counter is not accessed in the body of the loop (an assumption which (1) violates). The combination of these factors caused a perfect storm in which the code worked properly nearly all of the time: for loops that got unrolled, (1) would introduce a double-increment, but loop unrolling would fail to notice it (since it assumes that ir_loop::counter is not accessed in the body of the loop), so it would unroll the loop the correct number of times. For loops that didn't get unrolled, (1) would introduce a double-increment, but then later when the IR was cloned for linking, (2) would prevent the loop counter from being cloned properly, so it would look to further analysis stages like an independent variable (and hence the double-increment would stop occurring). At the end of linking, (3) would prevent the loop counter from being reparented, so it would still belong to the shader object rather than the linked program object. Provided that the client program didn't delete the shader object, the memory would never get reclaimed, and so the shader would function properly. However, for loops that didn't get unrolled, if the client program did delete the shader object, and the memory belonging to the loop counter got re-used, this could cause a use-after-free bug, leading to a crash. This patch fixes loop_control_visitor, ir_clone, and ir_hierarchical_visitor to treat ir_loop::counter the same way the back-ends treat it: as a freshly allocated ir_variable that needs to be visited and cloned independently of other ir_variables. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=72026 Reviewed-by: Eric Anholt <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]>
* glsl: Teach ir_variable_refcount about ir_loop::counter variables.Paul Berry2013-11-292-0/+22
| | | | | | | | | | | | | | | | | If an ir_loop has a non-null "counter" field, the variable referred to by this field is implicitly read and written by the loop. We need to account for this in ir_variable_refcount, otherwise there is a danger we will try to dead-code-eliminate the loop counter variable. Note: at the moment the dead code elimination bug doesn't occur due to a bug in ir_hierarchical_visitor: it doesn't visit the "counter" field, so dead code elimination doesn't treat it as a candidate for elimination. But the patch to follow will fix that bug, so we need to fix ir_variable_refcount first in order to avoid breaking dead code elimination. Reviewed-by: Eric Anholt <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]>
* mesa: fix mem leak of glPixelMap data in display listBrian Paul2013-11-291-13/+16
| | | | | | And simplify save_PixelMapfv() by using the memdup() function. Reviewed-by: Ian Romanick <[email protected]>
* mesa: added memory-related comment in save_error()Brian Paul2013-11-291-0/+4
| | | | Reviewed-by: Ian Romanick <[email protected]>
* mesa: fix flags assignment in save_WaitSync()Brian Paul2013-11-291-1/+1
| | | | | | | | The flags value is a bitfield so use the union's 'bf' field, not 'e' (enum) field. There's no actual change in behavior here since both fields of the union are the same size. Reviewed-by: Ian Romanick <[email protected]>
* mesa: remove old colortable, histogram, etc. code from dlist.cBrian Paul2013-11-291-551/+0
| | | | | | | Trying to compile any of these functions into a display list now just generates a GL_INVALID_OPERATION error. Reviewed-by: Ian Romanick <[email protected]>
* mesa: have old convolution functions generate GL_INVALID_OPERATIONBrian Paul2013-11-291-12/+12
| | | | Reviewed-by: Ian Romanick <[email protected]>
* mesa: have old glColorTable functions generate GL_INVALID_OPERATIONBrian Paul2013-11-291-10/+10
| | | | | | As is done for the old histogram functions. Reviewed-by: Ian Romanick <[email protected]>
* trace: Dump PIPE_QUERY_* enums.José Fonseca2013-11-287-15/+98
| | | | Reviewed-by: Roland Scheidegger <[email protected]>
* trace: Dump query results faithfully.José Fonseca2013-11-283-15/+133
| | | | Reviewed-by: Roland Scheidegger <[email protected]>
* gallium/cso: fix sampler / sampler_view countsRoland Scheidegger2013-11-281-11/+16
| | | | | | | | | Now that it is possible to query drivers for the max sampler view it should be safe to increase this without crashing. Not entirely convinced this really works correctly though if state trackers using non-linked sampler / sampler_views use this. Reviewed-by: Jose Fonseca <[email protected]>
* gallium: new shader cap bit for the amount of sampler viewsRoland Scheidegger2013-11-2815-8/+33
| | | | | | | | | Ever since introducing separate sampler and sampler view max this was really missing. Every driver but llvmpipe reports the same number as number of samplers for now, so nothing should break. Reviewed-by: Jose Fonseca <[email protected]>
* gallium/drivers: support more sampler views than samplers for more driversRoland Scheidegger2013-11-286-7/+7
| | | | | | | | | This adds support for this to more drivers, in particular for all the "special" ones useful for debugging. HW drivers are left alone, some should be able to support it if they want but they may not be interested at this point. Reviewed-by: Jose Fonseca <[email protected]>
* i965: Properly reject __DRI_CTX_FLAG_ROBUST_BUFFER_ACCESS when ↵Ian Romanick2013-11-273-4/+18
| | | | | | | | | | | | | | | | | | | __DRI2_ROBUSTNESS is not enabled Only allow __DRI_CTX_FLAG_ROBUST_BUFFER_ACCESS in brwCreateContext if intelInitScreen2 also enabled __DRI2_ROBUSTNESS (thereby enabling GLX_ARB_create_context). This fixes a regression in the piglit test "glx/GLX_ARB_create_context/invalid flag" v2: Remove commented debug code. Noticed by Jordan. Signed-off-by: Ian Romanick <[email protected]> Reported-by: Paul Berry <[email protected]> Reviewed-by: Jordan Justen <[email protected]> Reviewed-by: Matt Turner <[email protected]> Cc: "10.0" <[email protected]>
* Revert "drop old INTEL_DEBUG names for `perf` (fall) and `fs` (wm)"Matt Turner2013-11-271-0/+2
| | | | | | | This reverts commit 195994fe4cd851f4aed7fe32697f94c4188a96c8. It wasn't sent to the list, Ken didn't review it, and it breaks shader-db.
* glsl: Link glcpp with math library.Vinson Lee2013-11-271-1/+3
| | | | | | | | | | | | | This patch fixes this build error with Oracle Solaris Studio. libtool: link: /opt/solarisstudio12.3/bin/cc -g -o glcpp/glcpp glcpp.o prog_hash_table.o ./.libs/libglcpp.a Undefined first referenced symbol in file sqrt prog_hash_table.o Signed-off-by: Vinson Lee <[email protected]> Reviewed-by: Brian Paul <[email protected]> Reviewed-by: Matt Turner <[email protected]>
* i965: Always reserve binding table space for at least one render target.Kenneth Graunke2013-11-271-1/+4
| | | | | | | | | | | | | | | | | | | | | In brw_update_renderbuffer_surfaces(), if there are no color draw buffers, we always set up a null render target at surface index 0 so we have something to use with the FB write marking the end of thread. However, when we recently began computing surface indexes dynamically, we failed to reserve space for it. This meant that the first texture would be assigned surface index 0, and our closing FB write would clobber the texture. Fixes Piglit's EXT_packed_depth_stencil/fbo-blit-d24s8 test on Gen4-5, which regressed as of commit 4e5306453da6a1c076309e543ec92d999e02f67a ("i965/fs: Dynamically set up the WM binding table offsets.") Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=70605 Signed-off-by: Kenneth Graunke <[email protected]> Reviewed-by: Chris Forbes <[email protected]> Tested-by: lu hua <[email protected]> Cc: "10.0" [email protected]
* glsl: Initialize _mesa_glsl_parse_state::atomic_counter_offsets before using it.Francisco Jerez2013-11-261-0/+2
| | | | | | Cc: Ian Romanick <[email protected]> Cc: "10.0" <[email protected]> Reviewed-by: Ian Romanick <[email protected]>
* i965/fs: Fix misleading comment.Francisco Jerez2013-11-261-1/+1
| | | | Reviewed-by: Kenneth Graunke <[email protected]>
* i965: Bump number of supported atomic counter buffers.Francisco Jerez2013-11-261-1/+1
| | | | | | | Now that we have dynamic binding tables there's no good reason anymore to expose so few atomic counter buffers. Increase it to 16. Reviewed-by: Kenneth Graunke <[email protected]>
* glsl/linker: Validate IR just before reparenting.Paul Berry2013-11-261-0/+5
| | | | | | | | | | | | | | | | | If reparent_ir() is called on invalid IR, then there's a danger that it will fail to reparent all of the necessary nodes. For example, if the IR contains an ir_dereference_variable which refers to an ir_variable that's not in the tree, that ir_variable won't get reparented, resulting in subtle use-after-free bugs once the non-reparented nodes are freed. (This is exactly what happened in the bug fixed by the previous commit). This patch makes this kind of bug far easier to track down, by transforming it from a use-after-free bug into an explicit IR validation error. Reviewed-by: Eric Anholt <[email protected]> Reviewed-by: Ian Romanick <[email protected]>
* glsl: Fix lowering of direct assignment in lower_clip_distance.Paul Berry2013-11-261-0/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In commit 065da16 (glsl: Convert lower_clip_distance_visitor to be an ir_rvalue_visitor), we failed to notice that since lower_clip_distance_visitor overrides visit_leave(ir_assignment *), ir_rvalue_visitor::visit_leave(ir_assignment *) wasn't getting called. As a result, clip distance dereferences appearing directly on the right hand side of an assignment (not in a subexpression) weren't getting properly lowered. This caused an ir_dereference_variable node to be left in the IR that referred to the old gl_ClipDistance variable. However, since the lowering pass replaces gl_ClipDistance with gl_ClipDistanceMESA, this turned into a dangling pointer when the IR got reparented. Prior to the introduction of geometry shaders, this bug was unlikely to arise, because (a) reading from gl_ClipDistance[i] in the fragment shader was rare, and (b) when it happened, it was likely that it would either appear in a subexpression, or be hoisted into a subexpression by tree grafting. However, in a geometry shader, we're likely to see a statement like this, which would trigger the bug: gl_ClipDistance[i] = gl_in[j].gl_ClipDistance[i]; This patch causes lower_clip_distance_visitor::visit_leave(ir_assignment *) to call the base class visitor, so that the right hand side of the assignment is properly lowered. Fixes piglit test: - spec/glsl-1.50/execution/geometry/clip-distance-itemized-copy Cc: Ian Romanick <[email protected]> Cc: "9.2" <[email protected]> Cc: "10.0" <[email protected]> Reviewed-by: Eric Anholt <[email protected]> Reviewed-by: Ian Romanick <[email protected]>
* i965/gs: Set GS prog_data to NULL if there is no GS program.Paul Berry2013-11-261-0/+7
| | | | | | | | | | | | | The previous commit fixes a bug wherein we would incorrectly refer to stale geometry shader prog_data when no geometry shader was active. This patch reduces the likelihood of that sort of bug occurring in the future by setting prog_data to NULL whenever there is no GS program. Cc: [email protected] Reviewed-by: Eric Anholt <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]>
* i965/gs: Properly skip GS binding table upload when no GS active.Paul Berry2013-11-261-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | Previously, in brw_gs_upload_binding_table(), we checked whether brw->gs.prog_data was NULL in order to determine whether a geometry shader was active. This didn't work: brw->gs.prog_data starts off as NULL, but it is set to non-NULL when a geometry shader program is built, and then never set to NULL again. As a result, if we called brw_gs_upload_binding_table() while there was no geometry shader active, but a geometry shader had previously been active, it would refer to a stale (and possibly freed) prog_data structure. This patch fixes the problem by modifying brw_gs_upload_binding_table() to use the proper technique to determine whether a geometry shader is active: by checking whether brw->geometry_program is NULL. This fixes the crash reported in comment 2 of bug 71870 (the incorrect rendering remains, however). Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=71870 Cc: [email protected] Reviewed-by: Chris Forbes <[email protected]> Reviewed-by: Eric Anholt <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]>
* dri: Allow __DRI_CTX_FLAG_ROBUST_BUFFER_ACCESS in driCreateContextAttribsIan Romanick2013-11-261-2/+4
| | | | | | | | Signed-off-by: Ian Romanick <[email protected]> Reported-by: Zhenyu Wang <[email protected]> Reviewed-by: Matt Turner <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]> Cc: "10.0" <[email protected]>
generated by cgit v1.2.3 (git 2.39.1) at 2024-12-21 00:15:09 +0000