| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Up until now, DRI3 was only used for devices that have render nodes, unless
overridden via an environment variable, with it falling back to DRI2 otherwise.
This limitation was there in order to support WL_bind_wayland_display as it
requires client opened device node fds to be authenticated, which isn't possible
when using DRI3. This is an unfortunate compromise as DRI3 provides security
benefits over DRI2.
Instead, allow DRI3 to be used for devices without render nodes but don't
advertise WL_bind_wayland_display in this case. Applications that need this
extension can still be run by disabling DRI3 support via the LIBGL_DRI3_DISABLE
environment variable.
Signed-off-by: Frank Binns <[email protected]>
Reviewed-by: Axel Davy <[email protected]>
|
|
|
|
|
|
|
| |
The generated GLSL header files were only being built for the host
platform, and not the target platform.
Trivial.
|
|
|
|
|
|
|
|
|
|
|
| |
The actual restriction is a little weaker than I originally thought. See
https://bugs.freedesktop.org/show_bug.cgi?id=92306#c17 for the
suggestion. This also explain why things weren't *always* failing
before, only sometimes. We will allocate a non-swizzled depth buffer for
NPOT winsys buffer sizes, which they almost always are.
Signed-off-by: Ilia Mirkin <[email protected]>
Cc: [email protected]
|
|
|
|
|
| |
Signed-off-by: Kenneth Graunke <[email protected]>
Reviewed-by: Ian Romanick <[email protected]>
|
|
|
|
|
| |
Signed-off-by: Ilia Mirkin <[email protected]>
Reviewed-by: Matt Turner <[email protected]>
|
|
|
|
|
|
|
|
|
| |
Until hardware appears (in a gallium driver) that can make use of the
TCS-outputted gl_BoundingBox, we just request that the variable gets
assigned as a regular patch variable.
Signed-off-by: Ilia Mirkin <[email protected]>
Reviewed-by: Ian Romanick <[email protected]>
|
|
|
|
|
| |
Signed-off-by: Ilia Mirkin <[email protected]>
Reviewed-by: Ian Romanick <[email protected]>
|
|
|
|
|
| |
Signed-off-by: Ilia Mirkin <[email protected]>
Reviewed-by: Ian Romanick <[email protected]>
|
|
|
|
|
| |
Signed-off-by: Ilia Mirkin <[email protected]>
Reviewed-by: Ian Romanick <[email protected]>
|
|
|
|
|
|
| |
Fixes misleading indentation warning in gcc.
Reviewed-by: Kenneth Graunke <[email protected]>
|
|
|
|
|
|
|
|
|
| |
blend is enabled.
Requested by Anuj during review of
4a87e4ade778e56d43333c65a58752b15a00ce69, adding as follow-up since it
led to assertion failures due to various GLSL bugs that should be
fixed now.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In the fragment shader OutputsWritten is a bitset of FRAG_RESULT_*
enumerants, which represent the location of each color output written
by the shader. The secondary and primary color outputs of a given
render target using dual-source blending have the same location, so
the 'idx' computation below will give the wrong bit as result if the
'var->data.index' term is non-zero -- E.g. if the shader writes the
primary and secondary colors of the FRAG_RESULT_COLOR output,
ir_set_program_inouts will think that the shader writes both
FRAG_RESULT_COLOR and FRAG_RESULT_SAMPLE_MASK, which is just bogus.
That would cause the brw_wm_prog_key::nr_color_regions computation
done in the i965 driver during fragment shader precompilation to be
wrong, which currently leads to unnecessary recompilation of shaders
that use dual-source blending, and triggers an assertion failure in
fs_visitor::emit_fb_writes() on my i965-fb-fetch branch.
Reviewed-by: Ilia Mirkin <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
built-in.
gl_SecondaryFragColorEXT should have the same location as gl_FragColor
for the secondary fragment color to be replicated to all fragment
outputs. The incorrect location of gl_SecondaryFragColorEXT would
cause the linker to mark both FRAG_RESULT_COLOR and FRAG_RESULT_DATA0
as being written to, which isn't allowed by the spec and would
ultimately lead to an assertion failure in
fs_visitor::emit_fb_writes() on my i965-fb-fetch branch.
This should also fix the code below for multiple dual-source-blended
render targets, which no driver currently supports but we have plans
to enable eventually in the i965 driver (the comment saying that no
hardware will ever support it seems rather hilarious).
Reviewed-by: Ilia Mirkin <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
fragment outputs.
Currently the mesa state tracker relies on there being two bits set
per dual-source output in the gl_program::OutputsWritten bitset, but
that only worked due to a GLSL front-end bug that caused it to set the
OutputsWritten bit for both location and location+1 even though at the
GLSL level the primary and secondary color outputs used for
dual-source blending have the same location. Fix it by extending
outputMapping[] to 2*FRAG_RESULT_MAX elements in order to represent a
mapping from a (location, index) pair to its TGSI output, which should
also make it slightly easier to add support for dual-source blending
in combination with multiple render targets in the long run.
No Piglit regressions on llvmpipe.
Reviewed-by: Ilia Mirkin <[email protected]>
|
|
|
|
| |
Reviewed-by: Ilia Mirkin <[email protected]>
|
|
|
|
|
|
| |
Trivial.
Signed-off-by: Ian Romanick <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
text data bss dec hex filename
7669233 277176 28624 7975033 79b079 i965_dri.so before generated code
7647081 277176 28624 7952881 7959f1 i965_dri.so before this commit
7669289 277176 28624 7975089 79b0b1 i965_dri.so with this commit
Looking at the generated assembly, it appears that some of changes made
in the generated code prevent some loops from being unrolled. Removing
the default cases (via unreachable()) allows these loops to unroll again.
Signed-off-by: Ian Romanick <[email protected]>
Reviewed-by: Matt Turner <[email protected]>
|
|
|
|
|
|
| |
Signed-off-by: Ian Romanick <[email protected]>
Reviewed-by: Matt Turner <[email protected]>
Acked-by: Dylan Baker <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
| |
constant_template_horizontal_single_implementation for unops
This changes the "shape" of all the pack and unpack operators, but they
should function the same.
Signed-off-by: Ian Romanick <[email protected]>
Reviewed-by: Matt Turner <[email protected]>
Acked-by: Dylan Baker <[email protected]>
|
|
|
|
|
|
|
|
|
| |
constant_template_common can now handle the case where the result type
is different from the input type by using type_signature_iter. This
changes the "shape" of all the cast-style operators, but they should
function the same.
Signed-off-by: Ian Romanick <[email protected]>
|
|
|
|
|
|
|
|
| |
constant_template_common can now handle the case where the result type
is different from the input type by using type_signature_iter.
Signed-off-by: Ian Romanick <[email protected]>
Reviewed-by: Matt Turner <[email protected]>
|
|
|
|
|
|
|
|
|
| |
This template is mostly an artefact of the development of the original
patch series and to minimize the differences between the original code
and the generated code.
Signed-off-by: Ian Romanick <[email protected]>
Reviewed-by: Matt Turner <[email protected]>
|
|
|
|
|
|
|
|
|
|
| |
The difference between these two templates were mostly an artefact of
the development of the original patch series and to minimize the
differences between the original code and the generated code.
Signed-off-by: Ian Romanick <[email protected]>
Reviewed-by: Matt Turner <[email protected]>
Acked-by: Dylan Baker <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Immediately previous to this patch,
diff -wud src/glsl/ir_constant_expression.cpp \
src/glsl/ir_expression_operation_constant.h
should be "minimal."
v3: With much help from José Fonseca, fix the SCons build.
Signed-off-by: Ian Romanick <[email protected]>
Reviewed-by: Matt Turner <[email protected]>
|
|
|
|
|
|
|
|
| |
v2: 'for (a, b) in d' => 'for a, b in d'. Suggested by Dylan.
Signed-off-by: Ian Romanick <[email protected]>
Reviewed-by: Matt Turner <[email protected]>
Acked-by: Dylan Baker <[email protected]>
|
|
|
|
|
|
|
|
| |
v2: 'for (a, b) in d' => 'for a, b in d'. Suggested by Dylan.
Signed-off-by: Ian Romanick <[email protected]>
Reviewed-by: Matt Turner <[email protected]>
Acked-by: Dylan Baker <[email protected]>
|
|
|
|
|
|
|
|
| |
v2: 'for (a, b) in d' => 'for a, b in d'. Suggested by Dylan.
Signed-off-by: Ian Romanick <[email protected]>
Reviewed-by: Matt Turner <[email protected]>
Acked-by: Dylan Baker <[email protected]>
|
|
|
|
|
|
|
|
| |
v2: 'for (a, b) in d' => 'for a, b in d'. Suggested by Dylan.
Signed-off-by: Ian Romanick <[email protected]>
Reviewed-by: Matt Turner <[email protected]>
Acked-by: Dylan Baker <[email protected]>
|
|
|
|
|
|
|
|
| |
v2: 'for (a, b) in d' => 'for a, b in d'. Suggested by Dylan.
Signed-off-by: Ian Romanick <[email protected]>
Reviewed-by: Matt Turner <[email protected]>
Acked-by: Dylan Baker <[email protected]>
|
|
|
|
|
|
|
|
| |
v2: 'for (a, b) in d' => 'for a, b in d'. Suggested by Dylan.
Signed-off-by: Ian Romanick <[email protected]>
Reviewed-by: Matt Turner <[email protected]>
Acked-by: Dylan Baker <[email protected]>
|
|
|
|
|
|
|
|
| |
v2: 'for (a, b) in d' => 'for a, b in d'. Suggested by Dylan.
Signed-off-by: Ian Romanick <[email protected]>
Reviewed-by: Matt Turner <[email protected]>
Acked-by: Dylan Baker <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
| |
expressions
ir_triop_bitfield_extract is a little weird because the second and third
operand and aways int, so they may differ in type from the first
operand.
Signed-off-by: Ian Romanick <[email protected]>
Reviewed-by: Matt Turner <[email protected]>
Acked-by: Dylan Baker <[email protected]>
|
|
|
|
|
|
|
|
| |
v2: 'for (a, b) in d' => 'for a, b in d'. Suggested by Dylan.
Signed-off-by: Ian Romanick <[email protected]>
Reviewed-by: Matt Turner <[email protected]>
Acked-by: Dylan Baker <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The code generated is quite different from what was previously used. I
believe that it is still correct by the GLSL spec, and I believe, due to
C rules about shifts, the behavior will be the same.
Section 5.9 (Expressions) of the GLSL 4.50 spec says:
The result is undefined if the right operand is negative, or greater
than or equal to the number of bits in the left expression's base
type.
Signed-off-by: Ian Romanick <[email protected]>
Reviewed-by: Matt Turner <[email protected]>
Acked-by: Dylan Baker <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
| |
ldexp is weird because its two operands have different types. Add
support for directly specifying the exact signatures of all the possible
variations of an operation.
v2: Use tuple() instead of () for clarity. Suggested by Dylan.
Signed-off-by: Ian Romanick <[email protected]>
Reviewed-by: Matt Turner <[email protected]>
Acked-by: Dylan Baker <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
destination
These are operations like the pack functions that have separate
functions that assign multiple outputs from a single input.
v2: Correct the source and destination types. They were previously
transposed.
Signed-off-by: Ian Romanick <[email protected]>
Reviewed-by: Matt Turner <[email protected]>
Acked-by: Dylan Baker <[email protected]>
|
|
|
|
|
|
|
|
|
|
| |
Only operations where the implementation is identical code regardless of
type. The only such operations are ir_binop_all_equal and
ir_binop_any_nequal.
Signed-off-by: Ian Romanick <[email protected]>
Reviewed-by: Matt Turner <[email protected]>
Acked-by: Dylan Baker <[email protected]>
|
|
|
|
|
|
| |
Signed-off-by: Ian Romanick <[email protected]>
Reviewed-by: Matt Turner <[email protected]>
Acked-by: Dylan Baker <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
| |
differs from the input types
v2: Remove extra int() cast in find_lsb. Suggested by Matt. 'for (a,
b) in d' => 'for a, b in d'. Suggested by Dylan.
Signed-off-by: Ian Romanick <[email protected]>
Reviewed-by: Matt Turner <[email protected]>
Acked-by: Dylan Baker <[email protected]>
|
|
|
|
|
|
|
|
|
|
| |
scalar operands
v2: 'for (a, b) in d' => 'for a, b in d'. Suggested by Dylan.
Signed-off-by: Ian Romanick <[email protected]>
Reviewed-by: Matt Turner <[email protected]>
Acked-by: Dylan Baker <[email protected]>
|
|
|
|
|
|
| |
Signed-off-by: Ian Romanick <[email protected]>
Reviewed-by: Matt Turner <[email protected]>
Acked-by: Dylan Baker <[email protected]>
|
|
|
|
|
|
|
|
|
|
| |
implementations for each source type
v2: 'for (a, b) in d' => 'for a, b in d'. Suggested by Dylan.
Signed-off-by: Ian Romanick <[email protected]>
Reviewed-by: Matt Turner <[email protected]>
Acked-by: Dylan Baker <[email protected]>
|
|
|
|
|
|
|
|
|
| |
ir_unop_i2b is omitted because its source can either be int or uint.
That makes it special.
Signed-off-by: Ian Romanick <[email protected]>
Reviewed-by: Matt Turner <[email protected]>
Acked-by: Dylan Baker <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
| |
Unary operations where all of the supported types use the same C
expression to evaluate them.
v2: 'for (a, b) in d' => 'for a, b in d'. Suggested by Dylan.
Signed-off-by: Ian Romanick <[email protected]>
Reviewed-by: Matt Turner <[email protected]>
Acked-by: Dylan Baker <[email protected]>
|
|
|
|
|
|
|
|
|
| |
This makes things a little more clear now, and it will make future
changes... possible.
Signed-off-by: Ian Romanick <[email protected]>
Reviewed-by: Matt Turner <[email protected]>
Acked-by: Dylan Baker <[email protected]>
|
|
|
|
|
|
|
| |
Even though they are much too long for that.
Signed-off-by: Ian Romanick <[email protected]>
Reviewed-by: Matt Turner <[email protected]>
|
|
|
|
|
| |
Signed-off-by: Ian Romanick <[email protected]>
Reviewed-by: Matt Turner <[email protected]>
|
|
|
|
|
| |
Signed-off-by: Ian Romanick <[email protected]>
Reviewed-by: Matt Turner <[email protected]>
|
|
|
|
|
| |
Signed-off-by: Ian Romanick <[email protected]>
Reviewed-by: Matt Turner <[email protected]>
|
|
|
|
|
| |
Signed-off-by: Ian Romanick <[email protected]>
Reviewed-by: Matt Turner <[email protected]>
|