summaryrefslogtreecommitdiffstats
Commit message (Collapse)AuthorAgeFilesLines
* mesa: remove ARB_geometry_shader4Marta Lofstedt2015-11-2611-141/+9
| | | | | | | | | | 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]>
* targets/xvmc: use the non-inline sw helpersMichel Dänzer2015-11-261-0/+1
| | | | | | | | | | | | | | | This was missed in commit 59cfb21d ("targets: use the non-inline sw helpers"). Fixes build failure: CXXLD libXvMCgallium.la ../../../../src/gallium/auxiliary/pipe-loader/.libs/libpipe_loader_static.a(libpipe_loader_static_la-pipe_loader_sw.o):(.data.rel.ro+0x0): undefined reference to `sw_screen_create' collect2: error: ld returned 1 exit status Makefile:756: recipe for target 'libXvMCgallium.la' failed make[3]: *** [libXvMCgallium.la] Error 1 Trivial.
* targets/nine: remove freedreno targetEmil Velikov2015-11-251-3/+0
| | | | | | | | Analogous to previous commit. As we no longer have anyone who uses NIR we can drop the link. Signed-off-by: Emil Velikov <[email protected]> Acked-by: Rob Clark <[email protected]>
* targets/nine: remove vc4 targetEmil Velikov2015-11-251-2/+0
| | | | | | | There are no users for it. Signed-off-by: Emil Velikov <[email protected]> Reviewed-by: Eric Anholt <[email protected]>
* gallium: remove unused function declarationsEmil Velikov2015-11-252-6/+0
| | | | | | | | Unused as of commit 23fb11455b4 "{st,targets}/dri: use static/dynamic pipe-loader" Signed-off-by: Emil Velikov <[email protected]> Reviewed-by: Ilia Mirkin <[email protected]>
* targets: use the non-inline sw helpersEmil Velikov2015-11-257-1/+8
| | | | | | | | | | | | | | | | | | Previously (with the inline ones) things were embedded into the pipe-loader, which means that we cannot control/select what we want in each target. That also meant that at runtime we ended up with the empty sw_screen_create() as the GALLIUM_SOFTPIPE/LLVMPIPE were not set. v2: Cover all the targets, not just dri. Cc: "11.1" <[email protected]> Cc: Ilia Mirkin <[email protected]> Cc: Edward O'Callaghan <[email protected]> Signed-off-by: Emil Velikov <[email protected]> Tested-by: Oded Gabbay <[email protected]> Tested-by: Nick Sarnie <[email protected]>
* target-hepers: add non inline sw helpersEmil Velikov2015-11-252-0/+83
| | | | | | | | | | | | Feeling rather dirty copying the inline ones, yet we need the inline ones for swrast only targets like libgl-xlib, osmesa. Cc: "11.1" <[email protected]> Cc: Ilia Mirkin <[email protected]> Cc: Edward O'Callaghan <[email protected]> Signed-off-by: Emil Velikov <[email protected]> Tested-by: Oded Gabbay <[email protected]> Tested-by: Nick Sarnie <[email protected]>
* pipe-loader: fix off-by one errorEmil Velikov2015-11-251-1/+1
| | | | | | | | | | | | | | | | With earlier commit we've dropped the manual iteration over the fixed size array and prepemtively set the variable storing the size, that is to be returned. Yet we forgot to adjust the comparison, as before we were comparing the index, now we're comparing the size. Fixes: ff9cd8a67ca "pipe-loader: directly use pipe_loader_sw_probe_null() at probe time" Cc: [email protected] Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=93091 Reported-by: Tom Stellard <[email protected]> Signed-off-by: Emil Velikov <[email protected]> Tested-by: Tom Stellard <[email protected]> Tested-by: Dieter Nützel <[email protected]>
* nir: include what we want/needEmil Velikov2015-11-251-1/+1
| | | | | | | | Swap core.h with macros.h, as the latter provides the required MAX2 macro. Signed-off-by: Emil Velikov <[email protected]> Reviewed-by: Jason Ekstrand <[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]>
* radeonsi/compute: Use the compiler's COMPUTE_PGM_RSRC* register valuesTom Stellard2015-11-252-31/+7
| | | | | | | | | The compiler has more information and is able to optimize the bits it sets in these registers. Reviewed-by: Marek Olšák <[email protected]> CC: <[email protected]>
* radeonsi: Rename si_shader::ls_rsrc{1,2} to si_shader::rsrc{1,2}Tom Stellard2015-11-253-6/+6
| | | | | | In the future, these will be used by other shaders types. Reviewed-by: Marek Olšák <[email protected]>
* docs: minimum required python mako version is 0.3.4Samuel Iglesias Gonsálvez2015-11-251-1/+1
| | | | | Signed-off-by: Samuel Iglesias Gonsálvez <[email protected]> Reviewed-by: Emil Velikov <[email protected]>
* docs: update relnotes with AMD_performance_monitor for radeonsiNicolai Hähnle2015-11-251-0/+1
| | | | Reviewed-by: Marek Olšák <[email protected]>
* radeonsi: implement AMD_performance_monitor for CIK+Nicolai Hähnle2015-11-2510-3/+1486
| | | | | | | | | | | | | | | | | | Expose most of the performance counter groups that are exposed by Catalyst. Ideally, the driver will work with GPUPerfStudio at some point, but we are not quite there yet. In any case, this is the reason for grouping multiple instances of hardware blocks in the way it is implemented. The counters can also be shown using the Gallium HUD. If one is interested to see how work is distributed across multiple shader engines, one can set the environment variable RADEON_PC_SEPARATE_SE=1 to obtain finer-grained performance counter groups. Part of the implementation is in radeon because an implementation for older hardware would largely follow along the same lines, but exposing a different set of blocks which are programmed slightly differently. Reviewed-by: Marek Olšák <[email protected]>
* radeon: scale query buffer size to result sizeNicolai Hähnle2015-11-251-1/+1
| | | | | | | Performance monitor queries can become very big, especially considering that instances of a block in different shader engines are queried separately. Reviewed-by: Marek Olšák <[email protected]>
* radeonsi/sid: add performance counter registersNicolai Hähnle2015-11-251-0/+1013
| | | | Reviewed-by: Marek Olšák <[email protected]>
* radeonsi/sid: add hardware constants for COPY_DATA packetNicolai Hähnle2015-11-251-0/+3
| | | | Reviewed-by: Marek Olšák <[email protected]>
* radeon: extend CIK_UCONFIG_REG_END for performance countersNicolai Hähnle2015-11-252-2/+2
| | | | Reviewed-by: Marek Olšák <[email protected]>
* radeon: add perfcounter-related EVENT_TYPEsNicolai Hähnle2015-11-251-0/+3
| | | | Reviewed-by: Marek Olšák <[email protected]>
* radeon: additional constants for WAIT_REG_MEM and EVENT_WRITE_EOPNicolai Hähnle2015-11-251-0/+8
| | | | Reviewed-by: Marek Olšák <[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]>
* glsl: handle case where index is array deref in optimize_split_arraysTapani Pälli2015-11-251-0/+4
| | | | | | | | | Previously pass did not traverse to those array dereferences which were used as indices to arrays. This fixes Synmark2 Gl42CSCloth application issues. Signed-off-by: Tapani Pälli <[email protected]> Reviewed-by: Juha-Pekka Heikkila <[email protected]>
* nouveau: move interlaced assert down in nouveau_vp3_video_buffer_createJulien Isorce2015-11-251-1/+1
| | | | | | | | templat->interlaced is 0 if not NV12 which is the case currently when using VPP. Signed-off-by: Julien Isorce <[email protected]> Reviewed-by: Ilia Mirkin <[email protected]>
* i965: remove trailing spaces in various filesIago Toral Quiroga2015-11-2511-34/+29
| | | | Acked-by: Kenneth Graunke <[email protected]>
* glsl: remove trailing spaces in various filesIago Toral Quiroga2015-11-254-9/+8
| | | | 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.
* glsl: only call dead code pass when new inputs/outputs demotedTimothy Arceri2015-11-251-10/+14
| | | | | | | This will help avoid eliminating inputs/outputs needed by SSOs. Cc: Gregory Hainaut <[email protected]> Reviewed-by: Juha-Pekka Heikkila <[email protected]>
* glsl: move and reused code to find first and last shadersTimothy Arceri2015-11-251-18/+12
| | | | Reviewed-by: Juha-Pekka Heikkila <[email protected]>
* 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]>
* meta: Use DSA functions for VBOs in _mesa_meta_setup_vertex_objectsIan Romanick2015-11-241-19/+24
| | | | | | | | | | The fixed-function attribute paths don't get the DSA treatment because there are no DSA entry-points for fixed-function attributes. These could have been added, but this is a temporary patch intended to make later patches easier to review. 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 handleIan Romanick2015-11-245-48/+72
| | | | | Signed-off-by: Ian Romanick <[email protected]> Reviewed-by: Anuj Phogat <[email protected]>
* meta: Don't leave the VBO bound after _mesa_meta_setup_vertex_objectsIan Romanick2015-11-245-21/+38
| | | | | | | | | Meta currently does this, but future changes will make this impossible. Explicitly do it as a step in the patch series now to catch any possible kinks. Signed-off-by: Ian Romanick <[email protected]> Reviewed-by: Anuj Phogat <[email protected]>
* i965: Use _mesa_NamedBufferSubData for users of _mesa_meta_setup_vertex_objectsIan Romanick2015-11-241-3/+3
| | | | | Signed-off-by: Ian Romanick <[email protected]> Reviewed-by: Anuj Phogat <[email protected]>
* meta: Use _mesa_NamedBufferData and _mesa_NamedBufferSubData for users of ↵Ian Romanick2015-11-243-10/+8
| | | | | | | _mesa_meta_setup_vertex_objects Signed-off-by: Ian Romanick <[email protected]> Reviewed-by: Anuj Phogat <[email protected]>
* meta: Use DSA functions for PBO in create_texture_for_pboIan Romanick2015-11-241-19/+11
| | | | | Signed-off-by: Ian Romanick <[email protected]> Reviewed-by: Anuj Phogat <[email protected]>
* i965: Don't pollute the buffer object namespace in brw_meta_fast_clearIan Romanick2015-11-241-5/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | 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: Abdiel Janulgue <[email protected]> Reviewed-by: Anuj Phogat <[email protected]>
generated by cgit v1.2.3 (git 2.39.1) at 2024-12-28 07:33:22 +0000