- 19 Feb, 2019 4 commits
-
-
Jonathan Marek authored
In freedreno_gmem.c, gmem_align of 0x8000 is used. Alignment used when patching should be the same. Signed-off-by:Jonathan Marek <jonathan@marek.ca>
-
Jonathan Marek authored
We can set REG_A2XX_RB_COPY_DEST_OFFSET in the tile init as it won't get touched by the draw batch. Then gmem2mem can appended to the draw batch. We can use gmem->bin_w/gmem->bin_h for the viewport, it will be scissored. Signed-off-by: -
Jonathan Marek authored
Signed-off-by: -
Jonathan Marek authored
FD_MESA_DEBUG options: tex1x1: force 1x1 textures (to debug lower perf systems) fragsolid: force solid fragment shader (not working) tile: render tile outlines (need to fix color changing) bypass: force gmem bypass for all batches (breaks alpha) GALLIUM_HUD options: tilecount: number of tiles pixelcount: number of pixels also causes GALLIUM_HUD to be opaque and forces gmem bypass for it
-
- 18 Feb, 2019 1 commit
-
-
Jonathan Marek authored
Signed-off-by:
-
- 06 Feb, 2019 12 commits
-
-
Jonathan Marek authored
Signed-off-by: -
Jonathan Marek authored
Signed-off-by:
Ilia Mirkin <imirkin@alum.mit.edu> Signed-off-by:
-
Jonathan Marek authored
Signed-off-by:
-
Jonathan Marek authored
Signed-off-by:
-
Jonathan Marek authored
Signed-off-by:
-
Jonathan Marek authored
Signed-off-by:
-
Jonathan Marek authored
Still has a hack for unexplained issue related to unabling reordering
-
Jonathan Marek authored
When ffma is available, we can use a different arrangement of constants to get a better result. On freedreno/ir3, this reduces the YUV->RGB to 7 scalar ffma. On freedreno/a2xx, it will allow YUV->RGB to be 3 vec4 ffma. Signed-off-by: -
Jonathan Marek authored
This works by moving the fadd up across the ffma operations, so that it can eventually can be combined with a fmul. I'm not sure it works in all cases, but it works in all the common cases. This will only affect freedreno since it is the only driver using the fuse_ffma option. Example: matrix * vec4(coord, 1.0) is compiled as: fmul, ffma, ffma, fadd and with this patch: ffma, ffma, ffma Signed-off-by: -
Fixes: 912a9c8d Signed-off-by:
-
Eric Engestrom authored
`EGLDisplay` variables (the opaque Khronos type) have mostly been consistently called `dpy`, as this is the name used in the Khronos specs. However, `_EGLDisplay` variables (our internal struct) have been randomly called `dpy` when there was no local variable clash with `EGLDisplay`s, and `disp` otherwise. Let's be consistent and use `dpy` for the Khronos type, and `disp` for our struct. Signed-off-by:
Eric Engestrom <eric.engestrom@intel.com> Acked-by:
Emil Velikov <emil.velikov@collabora.com> Acked-by:
Eric Anholt <eric@anholt.net>
-
Alyssa Rosenzweig authoredUntil the kernel side matures and the full driver is upstreamed, to avoid end-user surprises, Panfrost should only be built for the adventurous. Signed-off-by:
Alyssa Rosenzweig <alyssa@rosenzweig.io>
Reviewed-by:
-
- 05 Feb, 2019 23 commits
-
-
Emma Anholt authored
-
Emma Anholt authored
I had a single function for "does this do float input unpacking" with two major flaws: It was missing the most common thing to try to copy propagate a f32 input nunpack to (the VFPACK to an FP16 render target) along with several other ALU ops, and also would try to propagate an f32 unpack into a VFMUL which only does f16 unpacks. instructions in affected programs: 659232 -> 655895 (-0.51%) uniforms in affected programs: 132613 -> 135336 (2.05%) and a couple of programs increase their thread counts. The uniforms hit appears to be a pattern in generated code of doing (-a >= a) comparisons, which when a is abs(b) can result in the abs instruction being copy propagated once but not fully DCEed.
-
Emma Anholt authored
Avoids a regression in dEQP-GLES3.functional.shaders.derivate.fwidth.texture.* once we start copy-propagating more input packs.
-
Emma Anholt authored
We want to be able to copy propagate our texture unpacks into the vfpack.
-
Emma Anholt authored
We were trying to print a NULL entry from the table.
-
Emma Anholt authored
If you only bound rt 1+, we'd still emit a write to the rt0 that isn't present (noticed while debugging an ext_framebuffer_multisample-alpha-to-coverage-no-draw-buffer-zero regression in another change).
-
Emma Anholt authored
I was just leaving the other MRT targets than DATA0 out, by accident.
-
Kristian H. Kristensen authored
Fixes: cdc53fa8 Acked-by:
Kenneth Graunke <kenneth@whitecape.org>
Signed-off-by: Kristian H. Kristensen <hoegsberg@chromium.org>
-
Kenneth Graunke authoredIris would like to use compact arrays for tesslevels and clip/cull distances. radeonsi will likely want to switch to these at some point, since it'll be necessary for GL_ARB_gl_spirv support, but it's not ready for them just yet. Reviewed-by:Timothy Arceri <tarceri@itsqueeze.com>
-
Kenneth Graunke authored
Today, st always sets LowerCombinedClipCullDistance, causing the GLSL IR lowering to run, giving us vec4[2] arrays. I would like to disable this and instead run the NIR lowering so that we get compact float[] arrays instead. Calling the new pass is a noop if the GLSL IR pass has already run, so it's safe to call the pass unconditionally. Reviewed-by: -
Kenneth Graunke authored
Compact arrays are used for special variables like clip and cull distances, or tessellation levels. Drivers using compact arrays assume that these values will always be actual arrays. We don't want to turn a float[1] gl_CullDistance into a single float; that would confuse drivers. Today, i965 uses compact arrays, and Gallium drivers use nir_lower_io_arrays_to_elements, so we haven't had any overlap that would demonstrate the issue. Iris will use both. Reviewed-by: -
Kenneth Graunke authored
A couple places in st/nir assume that cull distances have been lowered away, so it will need to call this lowering pass for drivers which opt out of the GLSL IR lowering. The Intel backend also calls this pass, for i965 and anv. We need to only do it once. Reviewed-by: -
Kenneth Graunke authored
We have a GLSL IR pass to convert clip/cull distance float[] arrays into vec4[2] arrays. In ff281e62 , we attempted to skip this pass if the GLSL IR lowering had already run. But, that code was not quite right, as we forgot to strip away the per-vertex IO array layer for geometry and tessellation shader varyings. If the GLSL IR pass has run, the variables will not be marked as "compact". So we can simply check that and bail. Reviewed-by:
-
Kenneth Graunke authored
nir_lower_clip_cull_distance_arrays() marks the combined clip/cull distance array as compact. However, when translating in from GLSL or SPIR-V, we were not marking the original float[] arrays as compact. We should do so. That way, we can detect these corner cases properly. Reviewed-by: -
Kenneth Graunke authored
radeonsi uses a system value for gl_FragCoord rather than an input var. These get translated into load_frag_coord NIR intrinsics, which lose the pixel_center_integer and origin_upper_left decorations. To cope with this, Tim added a shader_info field for pixel_center_integer, and made glsl_to_nir set it accordingly. prog_to_nir also needs to handle these fragcoord conventions. Instead of duplicating the logic to set the info field, just move it to nir_lower_system_values so it'll happen regardless of who makes the NIR. (For what it's worth, we don't need an info flag for origin_upper_left, because radeonsi lowers origin conventions in nir_lower_wpos_ytransform before nir_lower_system_values destroys the variable and qualifiers.) Reviewed-by: -
Kenneth Graunke authored
Some drivers, such as radeonsi, use a system value for gl_FragCoord rather than an input variable. In this case, our Mesa IR will have a PROGRAM_SYSTEM_VALUE register, which we need to translate. This makes prog_to_nir work for Gallium drivers which expose the PIPE_CAP_TGSI_FS_POSITION_IS_SYSVAL capability bit. Reviewed-by: -
Kenneth Graunke authored
We can simply iterate the bits rather than using util_last_bit and checking each one up until that point. Reviewed-by: -
Kenneth Graunke authored
Acked-by:
Marek Olšák <marek.olsak@amd.com> Tested-by:
Rob Clark <robdclark@gmail.com> Tested-by:
-
Kenneth Graunke authored
Reviewed-by:
-
Kenneth Graunke authored
We implement the basic VS and FS, as well as the VS that does layered clears by writing gl_Layer from the vertex shader. Drivers which need a geometry shader for writing layer continue falling back to TGSI, as I didn't need this and so didn't bother implementing it. (We certainly could, however, if people want to add it in the future.) Reviewed-by:
-
Kenneth Graunke authored
Reviewed-by:
-
Kenneth Graunke authored
This provides a native NIR version of the DrawPixels/Bitmap passthrough vertex shader. Reviewed-by:
-
Kenneth Graunke authored
The state tracker generates several built-in shaders in order to perform scissored clears, upload/download PBOs, and so on. These are currently constructed using TGSI, using ureg and u_simple_shader. I want to have NIR versions of these shaders, for my Gallium driver that has a NIR backend but no TGSI support. To that end, we'll want a few helpers to help construct simple shaders. This patch adds two new helpers: - st_nir_finish_builtin_shader() takes a manually constructed NIR shader, applies lowering passes (like st_link_nir would do for GLSL), and constructs the pipe_shader_state. - st_nir_make_passthrough_shader() makes a simple passthrough shader, which copies inputs to outputs. This is similar to u_simple_shaders. v2: Set info->fs.untyped_color_outputs for vc4/v3d (thanks Eric!). Reviewed-by:
-
