summaryrefslogtreecommitdiffstats
Commit message (Collapse)AuthorAgeFilesLines
* 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-233-29/+62
| | | | | | | | | | | | | | | | | | | | | | | | | | | 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]>
* gallivm: do per-element lod for lod bias and explicit derivs tooRoland Scheidegger2013-08-222-31/+74
| | | | | | | | | | | | Except for explicit derivs with cube maps which are very bogus anyway. Just like explicit lod this is only used if no_quad_lod is set in GALLIVM_DEBUG env var. Minification is terrible on cpus which don't support true vector shifts (but should work correctly). Cannot do the min/mag filter decision (if they are different) per pixel though, only selecting different mip levels works. Reviewed-by: Jose Fonseca <[email protected]>
* gallivm: (trivial) fix int/uint border color clampingRoland Scheidegger2013-08-221-2/+2
| | | | | | | | | Just a copy & paste error. Fixes https://bugs.freedesktop.org/show_bug.cgi?id=68409. Note that the test passing before probably simply means it doesn't verify clamping of the border color itself as required by the OpenGL spec. Reviewed-by: Jose Fonseca <[email protected]>
* gallivm: (trivial) fix linear aos sampling of 3d compressed formatsRoland Scheidegger2013-08-221-2/+2
| | | | | | | | block size depth is always 1 even for compressed formats (unless someone invents true 3d compressed formats at least which we can't represent). Nearest (and soa) path had it right. Reviewed-by: Jose Fonseca <[email protected]>
* radeonsi: Fix y/z/w component values of TGSI_SEMANTIC_FOG pixel shader inputsMichel Dänzer2013-08-221-0/+18
| | | | | | | | | They are defined as constant 0.0/0.0/1.0. Three more little piglits. Cc: [email protected] Reviewed-by: Alex Deucher <[email protected]>
* gallium: Support PIPE_FORMAT_R10G10B10A2_UINT.José Fonseca2013-08-223-0/+3
| | | | | | Same as PIPE_FORMAT_B10G10R10A2_UINT but without the swizzling. Reviewed-by: Roland Scheidegger <[email protected]>
* trace: Handle null tokens.José Fonseca2013-08-221-2/+6
| | | | Used for example on stream out without geometry shader.
* ilo: do not need last shader stage for 3DSTATE_SBEChia-I Wu2013-08-224-14/+6
| | | | | | We have set up 3DSTATE_SBE (or 3DSTATE_SF on GEN6) in ilo_shader_select_kernel_routing(). There is no need to pass the last shader stage to the GPE function.
* ilo: fix a potential issue with STATE_SIPChia-I Wu2013-08-221-2/+2
| | | | | Command length is ORed to the wrong place. Since the ORed value is zero, there is no real change.
* ilo: add GEN check to 3DSTATE_CLIPChia-I Wu2013-08-221-0/+2
| | | | Assert that gen6_emit_3DSTATE_CLIP is for GEN 6 and 7.
* build: Add --enable-gallium-osmesa flag.Matt Turner2013-08-213-8/+27
| | | | | | | | The Gallium implementation is apparently not ready for regular consumption, so as much as I hate adding more build-time options, here's another. Acked-by: Brian Paul <[email protected]>
* glsl: Give a warning, not an error, for UBO qualifiers on non-matrices.Ian Romanick2013-08-211-6/+12
| | | | | | Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=59648 Reviewed-by: Matt Turner <[email protected]> Signed-off-by: Ian Romanick <[email protected]>
* glsl: Remove ubo_qualifiers_allowed variable.Matt Turner2013-08-214-11/+2
| | | | | | | No longer used. Reviewed-by: Ian Romanick <[email protected]> Reviewed-by: Anuj Phogat <[email protected]>
* glsl: Drop duplicate error messages.Matt Turner2013-08-211-12/+1
| | | | | | | | This same message is printed in the validate_matrix_layout_for_type function. Reviewed-by: Ian Romanick <[email protected]> Reviewed-by: Anuj Phogat <[email protected]>
* glsl: Rename ubo_qualifiers_valid to ubo_qualifiers_allowed.Matt Turner2013-08-214-6/+6
| | | | | | | | | The variable means that UBO qualifiers are allowed in a particular context (e.g., not allowed in a struct field declaration), rather than a particular set of UBO qualifiers are valid. Reviewed-by: Ian Romanick <[email protected]> Reviewed-by: Anuj Phogat <[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>
* svga: minor clean-ups in emit_hw_vs_vdecl()Brian Paul2013-08-211-6/+6
|
* gallivm: unify sin and cos implementationRoland Scheidegger2013-08-212-255/+53
| | | | | | | | | | | The (complicated!) math is all identical, there's just minimal differences how sign bit is calculated plus there's an additional subtraction for the argument going into the polynomial for cos. The logic stays 100% the same (with a small exception, sign bit calculation for sin is minimally simplified, applying sign mask after xoring the arguments instead of applying it to each argument). Reviewed-by: Jose Fonseca <[email protected]>
* gallivm: add comment for bogus min/mag filter selection with nearest mip filterRoland Scheidegger2013-08-213-2/+10
| | | | | | | Detected this hunting some other bug, not sure if it really needs fixing but it is definitely wrong. Reviewed-by: Jose Fonseca <[email protected]>
* gallivm: fix rho calculation for 1d caseRoland Scheidegger2013-08-211-1/+1
| | | | | | | Was using wrong (undefined) vector element (the elements are at 0/2 position, not 0/1). Reviewed-by: Jose Fonseca <[email protected]>
* 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]>
* glapi/gen: build temporary files in the build directoryMaarten Lankhorst2013-08-211-4/+4
| | | | | | | | | | Writing to the source directory can cause multiple parallel builds from the same source to fail. Create the temporary files in the build directory. Signed-off-by: Maarten Lankhorst <[email protected]> Reviewed-by: Matt Turner <[email protected]> Cc: "9.2" <[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]>
* glsl: Track existence of default float precision in GLSL ES fragment shadersIan Romanick2013-08-212-4/+68
| | | | | | | | | | | | | | | | | | | This is required by the spec, and it's a bit tricky because the default precision is scoped. As a result, I'm slightly abusing the symbol table. Fixes piglit no-default-float-precision.frag tests and the piglit default-precision-nested-scope-0[1234].frag tests that are currently on the piglit mailing list for review. On IRC I got confirmation from cwabbot that ARM (Mali T6xx and T400) enforces this requirement and from kusma that NVIDIA (Tegra2) enforces this requirement. We should be safe from regressing shipping applications. Signed-off-by: Ian Romanick <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]> Cc: "9.2" <[email protected]>
* glsl: Merge precision qualifiers tooIan Romanick2013-08-211-0/+3
| | | | | | | | | | | | | We never noticed this before because we previously didn't enfoce GLSL ES fragement shader requirements that precision be defined. There may also have been some interaction here with the addition of GL_ARB_shading_language_420pack, but it doesn't appear to me that it added any new bugs (just perhaps uncovered some old ones). Signed-off-by: Ian Romanick <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]> Reviewed-by: Matt Turner <[email protected]> Cc: "9.2" <[email protected]>
* glsl: Pass type to is_valid_default_precision_type instead of nameIan Romanick2013-08-211-4/+5
| | | | | | | | This is used by the next patch. Signed-off-by: Ian Romanick <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]> Cc: "9.2" <[email protected]>
* vdpau/decode: Fix comment.Rico Schüller2013-08-211-1/+1
| | | | Reviewed-by: Christian König <[email protected]>
* vl/query: Only support VDP_CHROMA_TYPE_420 for 12 bit formats.Rico Schüller2013-08-211-1/+6
| | | | Reviewed-by: Christian König <[email protected]>
* util: add avx2 and xop detection to cpu detection codeRoland Scheidegger2013-08-203-2/+59
| | | | | | | | | | Going to need this soon (not going to bother with avx2 intrinsics at this time but don't want to do workarounds for true vector shifts if llvm itself can use them just fine and won't need the gazillion instruction emulation). Not really tested other than my cpu returns 0 for these features... (I have no idea if llvm actually would emit avx2/xop instructions neither...) Reviewed-by: Jose Fonseca <[email protected]>
generated by cgit v1.2.3 (git 2.39.1) at 2024-12-24 18:43:28 +0000