summaryrefslogtreecommitdiffstats
path: root/src/mesa
Commit message (Collapse)AuthorAgeFilesLines
* mesa: Set query->EverBound in glQueryCounter().Kenneth Graunke2013-08-251-0/+1
| | | | | | | | | | | | | | | | | | | | | glIsQuery is supposed to return false for names returned by glGenQueries until their first use. BeginQuery is a use, but QueryCounter is also a use. From the ARB_timer_query spec: "A timer query object is created with the command void QueryCounter(uint id, enum target); [...] If <id> is an unused query object name, the name is marked as used [...]" Fixes Piglit's spec/ARB_timer_query/query-lifetime. Signed-off-by: Kenneth Graunke <[email protected]> Reviewed-by: Ian Romanick <[email protected]> Reviewed-by: Chad Versace <[email protected]> Cc: [email protected]
* i965/gs: Add a data structure for tracking VS output VUE map.Paul Berry2013-08-232-1/+16
| | | | | | Reviewed-by: Ian Romanick <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]> Reviewed-by: Matt Turner <[email protected]>
* i965/vec4: Make a function for setting up vec4 program key clip info.Paul Berry2013-08-232-6/+24
| | | | | | | | This functionality will need to be reused by geometry shaders. Reviewed-by: Ian Romanick <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]> Reviewed-by: Matt Turner <[email protected]>
* i965: Make prim_to_hw_prim accessible outside brw_draw.c.Paul Berry2013-08-232-1/+3
| | | | | | | | | We will need access to this array in order to configure the geometry shader. Reviewed-by: Ian Romanick <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]> Reviewed-by: Matt Turner <[email protected]>
* i965/gs: add GS visitors.Paul Berry2013-08-233-0/+351
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch introduces the vec4_gs_visitor class, which translates geometry shaders from GLSL IR to back-end opcodes. This class is derived from vec4_visitor (which is also the base class for vec4_vs_visitor), so as a result most of the back end code is shared. The only parts that differ are: - Geometry shaders use a different input payload organization, since the inputs need to match up with the outputs of the previous pipeline stage (vec4_gs_visitor::setup_payload() and vec4_gs_visitor::setup_varying_inputs()). - Geometry shader input array dereferences need a special stride computation, since all geometry shader inputs are interleaved into one giant array (vec4_gs_visitor::compute_array_stride()). - There are no geometry shader system values (vec4_gs_visitor::make_reg_for_system_value()). - At the beginning of a geometry shader, extra data in R0 needs to be zeroed out, and a vertex counter needs to be initialized (vec4_gs_visitor::emit_prolog()). - When EmitVertex() appears in the shader, the current contents of output variables need to be emitted to the URB, and the vertex counter needs to be incremented (vec4_gs_visitor::visit(ir_emit_vertex *)). - When generating a URB_WRITE message to output vertex data, the current state of the vertex counter needs to be used to store a write offset in the message header (vec4_gs_visitor::emit_urb_write_header()). - The URB_WRITE message that outputs vertex data needs to be sent using GS_OPCODE_URB_WRITE, since VS_OPCODE_URB_WRITE would overwrite the offsets in the message header (vec4_gs_visitor::emit_urb_write_opcode()). - At the end of a geometry shader, the final vertex count needs to be delivered using a URB WRITE message (vec4_gs_visitor::emit_thread_end()). - EndPrimitive() functionality is not implemented yet (vec4_gs_visitor::visit(ir_end_primitive *)). - There is no support for assembly shaders (vec4_gs_visitor::emit_program_code()). v2: Make num_input_vertices const. Refer to registers as rN rather than gN, for consistency with the PRM. Fix misspelling. Improve comment in the ir_emit_vertex visitor explaining why we emit vertices inside a conditional. Enclose the conditional code in the ir_emit_vertex visitor between curly braces. Reviewed-by: Ian Romanick <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]> Reviewed-by: Matt Turner <[email protected]>
* i965/gs: Add GS_OPCODE_SET_DWORD_2_IMMED.Paul Berry2013-08-234-0/+28
| | | | | | Reviewed-by: Ian Romanick <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]> Reviewed-by: Matt Turner <[email protected]>
* i965/gs: Add GS_OPCODE_SET_VERTEX_COUNT.Paul Berry2013-08-234-0/+45
| | | | | | Reviewed-by: Ian Romanick <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]> Reviewed-by: Matt Turner <[email protected]>
* i965/gs: Add GS_OPCODE_SET_WRITE_OFFSET.Paul Berry2013-08-234-0/+57
| | | | | | | | v2: Added a comment to vec4_generator::generate_gs_set_write_offset(). Reviewed-by: Ian Romanick <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]> Reviewed-by: Matt Turner <[email protected]>
* i965/gs: Add GS_OPCODE_THREAD_END.Paul Berry2013-08-235-0/+32
| | | | | | Reviewed-by: Ian Romanick <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]> Reviewed-by: Matt Turner <[email protected]>
* i965/gs: Add GS_OPCODE_URB_WRITE.Paul Berry2013-08-235-4/+38
| | | | | | Reviewed-by: Ian Romanick <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]> Reviewed-by: Matt Turner <[email protected]>
* i965/gs: Add a flag allowing URB write messages to use a per-slot offset.Paul Berry2013-08-232-2/+8
| | | | | | | | | | This will be used by geometry shaders to implement the EmitVertex() function, since it requires writing data to a dynamically-determined offset within the geometry shader's URB entry. Reviewed-by: Ian Romanick <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]> Reviewed-by: Matt Turner <[email protected]>
* i965: Combine 4 boolean args of brw_urb_WRITE into a flags bitfield.Paul Berry2013-08-2312-71/+76
| | | | | | | | | | | | The arguments to brw_urb_WRITE() were getting pretty unwieldy, and we have to add more flags to support geometry shaders anyhow. Also plumb these flags through brw_clip_emit_vue(), brw_set_urb_message(), and the vec4_instruction class. Reviewed-by: Ian Romanick <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]> Reviewed-by: Matt Turner <[email protected]>
* i965/gs: Add a case to brwNewProgram() for geometry shaders.Paul Berry2013-08-231-0/+11
| | | | | | Reviewed-by: Ian Romanick <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]> Reviewed-by: Matt Turner <[email protected]>
* i965/gs: Create structs for use by GS program compilation.Paul Berry2013-08-231-0/+23
| | | | | | | | v2: Make id "unsigned" rather than "GLuint". Reviewed-by: Ian Romanick <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]> Reviewed-by: Matt Turner <[email protected]>
* i965/gs: Add a case to brwBindProgram() for geometry shaders.Paul Berry2013-08-231-0/+3
| | | | | | Reviewed-by: Ian Romanick <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]> Reviewed-by: Matt Turner <[email protected]>
* i965/gs: Add brw->geometry_program.Paul Berry2013-08-232-0/+8
| | | | | | Reviewed-by: Ian Romanick <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]> Reviewed-by: Matt Turner <[email protected]>
* i965/vec4: Virtualize setup_payload instead of setup_attributes.Paul Berry2013-08-233-6/+5
| | | | | | | | | | | | | | | | | | | When I initially generalized the vec4_visitor class in preparation for geometry shaders, I assumed that the setup_attributes() function would need to be different between vertex and geometry shaders, but its caller, setup_payload(), could be shared. So I made setup_attributes() a virtual function. It turns out this isn't true; setup_payload() needs to be different too, since the geometry shader payload sometimes includes an extra register (primitive ID) that has to come before uniforms. So setup_payload() needs to be the virtual function instead of setup_attributes(). Reviewed-by: Ian Romanick <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]> Reviewed-by: Matt Turner <[email protected]>
* i965/vec4: Allow for dispatch_grf_start_reg to vary.Paul Berry2013-08-237-8/+20
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Both 3DSTATE_VS and 3DSTATE_GS have a dispatch_grf_start_reg control, which determines the register where the hardware delivers data sourced from the URB (push constants followed by per-vertex input data). For vertex shaders, we always set dispatch_grf_start_reg to 1, since R1 is always the first register available for push constants in vertex shaders. For geometry shaders, we'll need the flexibility to set dispatch_grf_start_reg to different values depending on the behvaiour of the geometry shader; if it accesses gl_PrimitiveIDIn, we'll need to set it to 2 to allow the primitive ID to be delivered to the thread in R1. This patch eliminates the assumption that dispatch_grf_start_reg is always 1. In vec4_visitor, we record the regnum that was passed to vec4_visitor::setup_uniforms() in prog_data for later use. In vec4_generator, we consult this value when converting an abstract UNIFORM register to a concrete hardware register. And in the code that emits 3DSTATE_VS, we set dispatch_grf_start_reg based on the value recorded in prog_data. This will allow us to set dispatch_grf_start_reg to the appropriate value when compiling geometry shaders. Vertex shaders will continue to always use a dispatch_grf_start_reg of 1. v2: Make dispatch_grf_start_reg "unsigned" rather than "GLuint". Reviewed-by: Ian Romanick <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]> Reviewed-by: Matt Turner <[email protected]>
* i965/vec4: Move vec4 data structures and functions to brw_vec4.{cpp,h}.Paul Berry2013-08-234-64/+72
| | | | | | | | | | | | | | | | This patch moves the following things into brw_vec4.{cpp,h}: - struct brw_vec4_compile - struct brw_vec4_prog_key - brw_vec4_prog_data_compare() - brw_vec4_prog_data_free() This will allow us to avoid having to include brw_vs.h in geometry-shader-specific files. Reviewed-by: Ian Romanick <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]> Reviewed-by: Matt Turner <[email protected]>
* i965: Make brw_{shader,vec4}.h safe to include from C.Paul Berry2013-08-232-2/+15
| | | | | | | | | | | | | | The patch that follows will move the definition of struct brw_vec4_prog_key from brw_vs.h to brw_vec4.h, making it necessary for brw_vs.h to include brw_vec4.h (because brw_vs.h defines struct brw_vs_prog_key, which contains brw_vec4_prog_key as a member). Since brw_vs.h is included from C source files, that means that brw_vec4.h will need to be safe to include from C. Same for brw_shader.h, since it is included by brw_vec4.h. Reviewed-by: Ian Romanick <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]> Reviewed-by: Matt Turner <[email protected]>
* i965: Stop including brw_vs.h from brw_vec4.h.Paul Berry2013-08-236-1/+9
| | | | | | | | | | | | | | | | This is backwards from what we are going to want in the long term, which is: - brw_vec4.h declares general-purpose vec4 infrastructure needed by both VS and GS - brw_vs.h includes brw_vec4.h and adds VS-specific parts. - brw_gs.h includes brw_vec4.h and adds GS-specific parts. Note that at the moment brw_vec.h contains a fair amount of VS-specific declarations--I plan to address that in a later patch. Reviewed-by: Ian Romanick <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]> Reviewed-by: Matt Turner <[email protected]>
* i965: Initialize all elements of ctx->ShaderCompilerOptions.Paul Berry2013-08-231-1/+1
| | | | | | | | | Otherwise any GS that requires lowering (e.g. one that uses gl_ClipDistance as an input or output) will fail to work. Reviewed-by: Ian Romanick <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]> Reviewed-by: Matt Turner <[email protected]>
* i965: Make brw_{program,vs}.h safe to include from C++.Paul Berry2013-08-233-1/+17
| | | | | | Reviewed-by: Ian Romanick <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]> Reviewed-by: Matt Turner <[email protected]>
* mesa/program: Make prog_instruction.h and program.h safe to include from C++.Paul Berry2013-08-232-0/+16
| | | | | | Reviewed-by: Ian Romanick <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]> Reviewed-by: Matt Turner <[email protected]>
* glsl: Refactor handling of gl_ClipDistance/gl_ClipVertex linkage rules for GS.Paul Berry2013-08-232-0/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | This patch extracts the following logic from validate_vertex_shader_executable(): (a) Generate an error if the shader writes to both gl_ClipDistance and gl_ClipVertex. (b) Record whether the shader writes to gl_ClipDistance in gl_shader_program for use by the back-end. (c) Record the size of gl_ClipDistance in gl_shader_program for use by transform feedback logic. And moves it into a function that is shared between vertex and geometry shaders. Strictly speaking we only need to have shared logic for (b) and (c) right now (since (a) only matters in compatibility contexts, and we're only implementing geometry shaders in core contexts right now). But the three are closely related enough that it seems sensible to keep them together. Reviewed-by: Kenneth Graunke <[email protected]> Reviewed-by: Ian Romanick <[email protected]> Reviewed-by: Matt Turner <[email protected]>
* mesa: Fix assertion error with glDebugMessageControlTimothy Arceri2013-08-231-13/+2
| | | | | | | | | | | enums were being converted twice resulting in incorrect values. The extra conversion has been removed and the redundant assert is removed also. Cc: 9.2 <[email protected]> Signed-off-by: Timothy Arceri <[email protected]> Reviewed-by: Brian Paul <[email protected]>
* mesa: Specify a better GL_MAX_SERVER_WAIT_TIMEOUT limit.Kenneth Graunke2013-08-221-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | The previous value of (GLuint64) ~0 has some problems: GL_MAX_SERVER_WAIT_TIMEOUT is supposed to be a GLuint64 value, but has to be queried via GetInteger64v(), which returns a GLint64. This means that some applications are likely to treat it as a signed integer, where ~0 means -1. Negative values are nonsensical and problematic. When interpreted correctly, ~0 translates to about 0.58 million years, which seems rather excessive. This patch changes it to 0x1fff7fffffff, which is about 1.11 years. This is still plenty long, and is the same as both an int64 and uint64. Applications that accidentally store it in a 32-bit int/unsigned also get a non-negative value, which is again the same as both int and unsigned. This value was suggested by Ian Romanick. v2: Add the ULL prefix on the constant (suggested by Ian). Fixes Piglit's spec/!OpenGL 3.2/get-integer-64v. Signed-off-by: Kenneth Graunke <[email protected]> Cc: [email protected]
* meta: Set correct viewport and projection in decompress_texture_image.Kenneth Graunke2013-08-221-0/+5
| | | | | | | | | | | | | | | | _mesa_meta_begin() sets up an orthographic project and initializes the viewport based on the current drawbuffer's width and height. This is likely the window size, since it occurs before the meta operation binds any temporary buffers. decompress_texture_image needs the viewport to be the size of the image it's trying to draw. Otherwise, it may only draw part of the image. v2: Actually set the projection properly too. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=68250 Signed-off-by: Kenneth Graunke <[email protected]> Cc: Mak Nazecic-Andrlon <[email protected]>
* i965: Fix misapplication of gles3 srgb workaroundChad Versace2013-08-221-3/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Fixes inconsistent failure of gles2conform/GL2Tests/glUniform/glUniform.test under gnome-shell. What follows is a description of the bug and its fix. When intel_update_renderbuffers() allocates a miptree for a winsys renderbuffer, it propagates the renderbuffer's format to become also the miptree's format. If the winsys color buffer format is SARGB, then, in the first call to eglMakeCurrent, intel_gles3_srgb_workaround() changes the renderbuffer's format to ARGB. That is, it changes the format from sRGB to non-sRGB. However, it changes the renderbuffer's format *after* intel_update_renderbuffers() has allocated the renderbuffer's miptree. Therefore, when eglMakeCurrent returns, the miptree format (SARGB) differs from the renderbuffer format (ARGB). If the X server reallocates the color buffer, intel_update_renderbuffers() will create a new miptree for the renderbuffer. The new miptree's format (ARGB) will differ from old miptree's format (SARGB). This mismatch between old and new miptrees causes bugs. Fix the bug by moving intel_gles3_srgb_workaround() to occur *before* intel_update_renderbuffers(). CC: "9.2" <[email protected]> Reviewed-by: Ian Romanick <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=67934 Signed-off-by: Chad Versace <[email protected]>
* i965/fs: Add code to print out global copy propagation sets.Kenneth Graunke2013-08-211-0/+30
| | | | | | | | | This was invaluable when debugging the global copy propagation algorithm. We may as well commit it in case someone needs to print out the sets in the future. Signed-off-by: Kenneth Graunke <[email protected]> Reviewed-by: Paul Berry <[email protected]>
* osmesa: Symlink shared library to LIB_DIRArmin K2013-08-211-0/+1
| | | | | | Cc: 9.2 <[email protected]> Tested-by: Brian Paul <brianp at vmware.com> Reviewed-by: Brian Paul <brianp at vmware.com>
* i965/gen7: Set MOCS L3 cacheability for IVB/BYT (v2)Ville Syrjälä2013-08-218-17/+12
| | | | | | | | | | | | | | | | IVB/BYT also has the same L3 cacheability control in MOCS as HSW, so let's make use of it. pts/xonotic and pts/reaction @ 1920x1080 gain ~4% on my IVB GT2. Most other things show less gains/no regressions, except furmark which loses some 10 points. I didn't have a BYT at hand for testing. v2: Don't check (brw->gen == 7) in gen7 functions. (chadv) Signed-off-by: Ville Syrjälä <[email protected]> Reviewed-by: Chad Versace <[email protected]>
* i965/hsw: Populate MOCS for STATE_BASE_ADDRESS (v2)Ville Syrjälä2013-08-212-3/+11
| | | | | | | | | | | Just spotted these unpopulated MOCS fields when comparing the code against BSpec. Set the MOCS to the same as everywhere else in Haswell: L3-cacheable. v2: Annotate state packet fields (chadv). Signed-off-by: Ville Syrjälä <[email protected]> Reviewed-by: Chad Versace <[email protected]>
* mesa: Never advertise _S3TC compressed formatsIan Romanick2013-08-211-12/+0
| | | | | | | | | | | | The NVIDIA driver doesn't expose them, and piglit's arb_texture_compression-invalid-formats expects them to not be there. This, with the previous commit, fixes piglit arb_texture_compression-invalid-formats. Signed-off-by: Ian Romanick <[email protected]> Reviewed-by: Anuj Phogat <[email protected]> Cc: "9.2" <[email protected]>
* mesa: Only advertise GL_ETC1_RGB8_OES in ES contextsIan Romanick2013-08-211-1/+9
| | | | | | | | | There is no extension for this format in desktop GL, so an application can't give the format back to glCompressedTexImage2D. Signed-off-by: Ian Romanick <[email protected]> Reviewed-by: Anuj Phogat <[email protected]> Cc: "9.2" <[email protected]>
* mesa: use ARRAY_SIZE() macro instead of magic numberBrian Paul2013-08-201-1/+1
| | | | Reviewed-by: Kenneth Graunke <[email protected]>
* i965: Shorten sampler loops in precompile key setup.Kenneth Graunke2013-08-202-2/+4
| | | | | | | | | | | | | | | Now that we have the number of samplers available, we don't need to iterate over all 16. This should be particularly helpful for vertex shaders. v2: Use the correct shader program (caught by Paul Berry). This needs to initialize the exact same set of sampler swizzles as the actual key setup, or else we end up doing recompiles due to some being XYZW and others being 0. Signed-off-by: Kenneth Graunke <[email protected]> Reviewed-by: Paul Berry <[email protected]>
* meta: Add default precision qualifier to all fragement shadersIan Romanick2013-08-191-0/+18
| | | | | | Signed-off-by: Ian Romanick <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]> Cc: "9.2" <[email protected]>
* i965: Make the VS binding table as small as possible.Kenneth Graunke2013-08-191-3/+4
| | | | | | | | For some reason, we didn't use this information even though the VS backend has computed it (albeit poorly) for ages. Signed-off-by: Kenneth Graunke <[email protected]> Reviewed-by: Paul Berry <[email protected]>
* i965/vs: Rework binding table size calculation.Kenneth Graunke2013-08-195-16/+20
| | | | | | | | | | | | | | | | | | | | | | Unlike the FS, the VS backend already computed the binding table size. However, it did so poorly: after compilation, it looked to see if any pull constants/textures/UBOs were in use, and set num_surfaces to the maximum surface index for that category. If the VS only used a single texture or UBO, this overcounted by quite a bit. The shader time surface was also noted at state upload time (during drawing), not at compile time, which is inefficient. I believe it also had an off by one error. This patch computes it accurately, while also simplifying the code. It also renames num_surfaces to binding_table_size, since num_surfaces wasn't actually the number of surfaces used. For example, a VS that used one UBO and no other surfaces would have set num_surfaces to SURF_INDEX_VS_UBO(1) == 18, rather than 1. A bit of a misnomer there. Signed-off-by: Kenneth Graunke <[email protected]> Reviewed-by: Paul Berry <[email protected]>
* i965/vs: Plumb brw_vec4_prog_data into vec4_generator().Kenneth Graunke2013-08-193-3/+7
| | | | | | | This will be useful for the next commit. Signed-off-by: Kenneth Graunke <[email protected]> Reviewed-by: Paul Berry <[email protected]>
* i965/fs: Make the FS binding table as small as possible.Kenneth Graunke2013-08-191-6/+5
| | | | | | | | | | | | | | Computing the minimum size was easy, and done at compile-time for no extra overhead here. Making the binding table smaller wastes less batch space. Adding the CACHE_NEW_WM_PROG dirty bit isn't strictly necessary, since other atoms depend on it and flag BRW_NEW_SURFACES. However, it's best to add it for clarity and safety. It shouldn't add any new overhead. v2: Use binding_table_size, rather than max_surface_index. Signed-off-by: Kenneth Graunke <[email protected]>
* i965/fs: Track the binding table size in brw_wm_prog_data.Kenneth Graunke2013-08-193-0/+27
| | | | | | | | | | | | | | | By tracking the maximum surface index used by the shader, we know just how small we can make the binding table. Since it depends entirely on the shader program, we can just compute it once at compile time, rather than at binding table emit time (which happens during drawing). v2: Store binding_table_size, rather than max_surface_index, for consistency with the VS (which needs to be able to represent 0 surfaces). Signed-off-by: Kenneth Graunke <[email protected]>
* i965: Use SURF_INDEX_DRAW() for drawbuffer binding table indices.Kenneth Graunke2013-08-194-17/+15
| | | | | | | | | | | | | | | | | | | | | SURF_INDEX_DRAW() has been the identity function since the dawn of time, and both the shader code and binding table upload code relied on that, simply using X rather than SURF_INDEX_DRAW(X). Even if that continues to be true, using the macro clarifies the code. The comment about draw buffers needing to be first in order for headerless render target writes to work turned out to be wrong; with this change, SURF_INDEX_DRAW can be changed to arbitrary indices and everything continues working. The confusion was over the "Render Target Index" field in the FB write message header. If it were a binding table index, then RT 0 would have to be at index 0 for headerless FB writes to work. However, it's actually an index into the blend state table, so there's no problem. Signed-off-by: Kenneth Graunke <[email protected]> Cc: Paul Berry <[email protected]>
* i965: Shorten sampler loops in key setup.Kenneth Graunke2013-08-193-3/+7
| | | | | | | | | Now that we have the number of samplers available, we don't need to iterate over all 16. This should be particularly helpful for vertex shaders. Signed-off-by: Kenneth Graunke <[email protected]> Reviewed-by: Paul Berry <[email protected]>
* i965: Make sampler counts available for the entire drawing operation.Kenneth Graunke2013-08-194-20/+20
| | | | | | | | | Previously, we computed sampler counts when generating the SAMPLER_STATE table. By computing it earlier, we should be able to shorten a bunch of loops. Signed-off-by: Kenneth Graunke <[email protected]> Reviewed-by: Paul Berry <[email protected]>
* i965: Split the brw_samplers atom into separate FS/VS stages.Kenneth Graunke2013-08-193-9/+28
| | | | | | | | This allows us to avoid uploading the VS sampler state table if only the fragment program changes. Signed-off-by: Kenneth Graunke <[email protected]> Reviewed-by: Paul Berry <[email protected]>
* i965: Upload separate VS and FS sampler state tables.Kenneth Graunke2013-08-193-18/+15
| | | | | | | | | Now, each shader stage has a sampler state table that only refers to the samplers actually used by that problem. This should make the VS table non-existant or very small. Signed-off-by: Kenneth Graunke <[email protected]> Reviewed-by: Paul Berry <[email protected]>
* i965: Make upload_sampler_state_table a virtual function.Kenneth Graunke2013-08-196-34/+30
| | | | | | | This allows us to coalesce the brw_samplers and gen7_samplers atoms. Signed-off-by: Kenneth Graunke <[email protected]> Reviewed-by: Paul Berry <[email protected]>
* i965: Upload separate per-stage sampler state tables.Kenneth Graunke2013-08-198-38/+72
| | | | | | | | | | | | | | Also upload separate sampler default/texture border color entries. At the moment, this is completely idiotic: both tables contain exactly the same contents, so we're simply wasting batch space and CPU time. However, soon we'll only upload data for textures actually /used/ in a particular stage, which will usually make the VS table empty and very likely eliminate all redundancy. This is just a stepping stone. Signed-off-by: Kenneth Graunke <[email protected]> Reviewed-by: Paul Berry <[email protected]>
generated by cgit v1.2.3 (git 2.39.1) at 2024-12-26 11:17:44 +0000