| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
| |
We were already using strdup() in various places in Mesa. Get rid
of the _mesa_strdup() wrapper. All the callers pass a non-NULL
argument so the NULL check isn't needed either.
Reviewed-by: Jose Fonseca <[email protected]>
Reviewed-by: Ian Romanick <[email protected]>
|
|
|
|
|
| |
Reviewed-by: Jose Fonseca <[email protected]>
Reviewed-by: Ian Romanick <[email protected]>
|
|
|
|
|
| |
Reviewed-by: Jose Fonseca <[email protected]>
Reviewed-by: Ian Romanick <[email protected]>
|
|
|
|
| |
Signed-off-by: Brian Paul <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The piglit test glsl-fs-uniform-array-loop-unroll.shader_test was designed
to do an out of bounds access into an uniform array to make sure that we
handle that situation gracefully inside the driver, however, as Ken describes
in bug 79202, Valgrind reports that this is leading to an out-of-bounds access
in fs_visitor::demote_pull_constants().
Before accessing the pull_constant_loc array we should make sure that
the uniform we are trying to access is valid.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=79202
Reviewed-by: Matt Turner <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Same idea as this patch, only for gen6_gs_visitor:
commit 49a938a265f5959c9b558995cc658f80acb6eb18
Author: Jordan Justen <[email protected]>
Date: Fri Feb 20 12:12:25 2015 -0800
i965/fs: Use fs_reg for CS/VS atomics pixel mask immediate data
Suggested-by: Matt Turner <[email protected]>
Signed-off-by: Jordan Justen <[email protected]>
Reviewed-by: Chris Forbes <[email protected]>
Reviewed-by: Matt Turner <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
brw_imm_ud(0xffff) should have been converted to fs_reg(0xffffu) to
make sure the uint32_t fs_reg constructor was matched.
commit 49a938a265f5959c9b558995cc658f80acb6eb18
Author: Jordan Justen <[email protected]>
Date: Fri Feb 20 12:12:25 2015 -0800
i965/fs: Use fs_reg for CS/VS atomics pixel mask immediate data
Signed-off-by: Jordan Justen <[email protected]>
Reviewed-by: Matt Turner <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We now skip allocating a hiz miptree for gen8. Instead, we calculate
the required hiz buffer parameters and allocate a bo directly.
v2:
* Update hz_height calculation as suggested by Topi
v3:
* Bail if we failed to create the bo (Ben)
v4:
* CEILING => DIV_ROUND_UP
* Make sure mt->logical_depth0 being 0 would not cause trouble
* Fail if Y tiling is not returned
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=67564
Signed-off-by: Jordan Justen <[email protected]>
Reviewed-by: Topi Pohjolainen <[email protected]>
Reviewed-by: Ben Widawsky <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We now skip allocating a hiz miptree for gen7. Instead, we calculate
the required hiz buffer parameters and allocate a bo directly.
v2:
* Update hz_height calculation as suggested by Topi
v3:
* Bail if we failed to create the bo (Ben)
v4:
* CEILING => DIV_ROUND_UP
* Make sure mt->logical_depth0 being 0 would not cause trouble
* Fail if Y tiling is not returned
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=67564
Signed-off-by: Jordan Justen <[email protected]>
Reviewed-by: Topi Pohjolainen <[email protected]>
Reviewed-by: Ben Widawsky <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
| |
We are still allocating a miptree for hiz, but we only use fields from
intel_miptree_aux_buffer. This will allow us to switch over to not
allocating a miptree.
Signed-off-by: Jordan Justen <[email protected]>
Reviewed-by: Topi Pohjolainen <[email protected]>
Reviewed-by: Kenneth Graunke <[email protected]>
Reviewed-by: Ben Widawsky <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
| |
We are still allocating a miptree for hiz, but we only use fields from
intel_miptree_aux_buffer. This will allow us to switch over to not
allocating a miptree.
Signed-off-by: Jordan Justen <[email protected]>
Reviewed-by: Topi Pohjolainen <[email protected]>
Reviewed-by: Kenneth Graunke <[email protected]>
Reviewed-by: Ben Widawsky <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Today we allocate a miptree's for the hiz buffer. We needed this in
the past because we would point the hardware at offsets of the hiz
buffer. Since the hiz format is not documented, this is not a good
idea.
Since moving to support layered rendering on Gen7+, we no longer point
at an offset into the buffer on Gen7+.
Therefore, to support hiz on Gen7+, we don't need a full miptree
structure allocated.
This patch starts to create a new auxiliary buffer structure
(intel_miptree_aux_buffer) that can be a more simplistic miptree
side-band buffer associated with a miptree. (For example, to serve the
needs of the hiz buffer.)
Signed-off-by: Jordan Justen <[email protected]>
Reviewed-by: Topi Pohjolainen <[email protected]>
Reviewed-by: Kenneth Graunke <[email protected]>
Reviewed-by: Ben Widawsky <[email protected]>
|
|
|
|
|
|
| |
Just noticed this when working on virgl.
Signed-off-by: Dave Airlie <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
| |
The maximum value of a Gallium HUD's panel is automatically adjusted
when the current value is greater than the max. If we set the
pipe_query_driver_info::max_value to UINT64_MAX, the maximum value is
never adjusted and this results in a flat line instead of a pretty curve
which is correctly scaled.
Signed-off-by: Samuel Pitoiset <[email protected]>
Reviewed-by: Ilia Mirkin <[email protected]>
|
|
|
|
|
|
|
|
|
|
| |
brw_shader.cpp: In function ‘bool brw_saturate_immediate(brw_reg_type, brw_reg*)’:
brw_shader.cpp:618:31: warning: ‘sat_imm.brw_saturate_immediate(brw_reg_type, brw_reg*)::<anonymous union>::ud’ may be used uninitialized in this function [-Wmaybe-uninitialized]
reg->dw1.ud = sat_imm.ud;
^
Signed-off-by: Vinson Lee <[email protected]>
Reviewed-by: Anuj Phogat <[email protected]>
|
|
|
|
|
|
|
|
|
|
| |
i915_fragprog.c: In function ‘i915ValidateFragmentProgram’:
i915_fragprog.c:1453:11: warning: variable ‘k’ set but not used [-Wunused-but-set-variable]
int k;
^
Signed-off-by: Vinson Lee <[email protected]>
Reviewed-by: Anuj Phogat <[email protected]>
|
|
|
|
|
|
| |
Suggested-by: Emil Velikov <[email protected]>
Signed-off-by: Vinson Lee <[email protected]>
Reviewed-by: Emil Velikov <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
It looks like this has existed since
commit f5a477ab76b6e0b268387699cd2253a43db0dfae
Author: Ian Romanick <[email protected]>
Date: Mon Dec 16 11:54:08 2013 -0800
meta: Refactor shader generation code out of mipmap generation path
Valgrind was complaining on fbo-generatemipmap-formats
v2: Instead, do the allocation after the early return block (v2)
Signed-off-by: Ben Widawsky <[email protected]>
Reviewed-by: Kenneth Graunke <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We used to loop over all color attachments, and emit FB writes for each
one, even if the shader didn't write to a corresponding output variable.
Those color attachments would be filled with garbage (undefined values).
Football Manager binds a framebuffer with 4 color attachments, but draws
to it using a shader that only writes to gl_FragData[0..2]. This meant
that color attachment 3 would be filled with garbage, resulting in
rendering artifacts. Now we skip writing to it, fixing rendering.
Writes to gl_FragColor initialize outputs[0..nr_color_regions-1] to
GRFs, while writes to gl_FragData[i] initialize outputs[i].
Thanks to Jason Ekstrand for tracking this down.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=86747
Signed-off-by: Kenneth Graunke <[email protected]>
Reviewed-by: Jason Ekstrand <[email protected]>
Cc: [email protected]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Previously, we emitted the shader-time epilogue from emit_fb_writes(),
during the middle of looping through color regions (or emit_urb_writes
for the VS). This is duplicated several times and rather awkward.
I need to fix a bug in our FB write handling, and it will be a lot
easier if we move emit_shader_time_end() out of there.
Now, we simply emit FB writes/URB writes, and subsequently have
emit_shader_time_end() insert instructions before the final SEND with
EOT. Not only is this simpler, it's actually a slight improvement:
we now include the MOVs to set up the final FB write payload in our
shader-time measurements.
Note that INTEL_DEBUG=shader_time only exists on Gen7+, and uses
send-from-GRF. (In the past, we might have hit trouble where both
attempt to use MRFs for messages; that's not a problem now.)
v2: Rebase on v3 of the previous patch and other shader_time fixes.
Signed-off-by: Kenneth Graunke <[email protected]>
Reviewed-by: Topi Pohjolainen <[email protected]> [v1]
Acked-by: Matt Turner <[email protected]>
Cc: [email protected]
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This makes another part of the INTEL_DEBUG=shader_time code emittable
at arbitrary locations, rather than just at the end of the instruction
stream.
v2: Don't lose smear! Caught by Topi Pohjolainen.
v3: Don't set smear on the destination of the MOV. Thanks Topi!
Signed-off-by: Kenneth Graunke <[email protected]>
Reviewed-by: Matt Turner <[email protected]>
Cc: [email protected]
|
|
|
|
|
|
|
|
|
|
|
|
| |
Instead of emit_shader_time_write, we now do emit(SHADER_TIME_ADD(...)).
The advantage is that we can also insert a shader time write at an
arbitrary location in the instruction stream, rather than being
restricted to emitting at the end.
Signed-off-by: Kenneth Graunke <[email protected]>
Reviewed-by: Topi Pohjolainen <[email protected]>
Reviewed-by: Matt Turner <[email protected]>
Cc: [email protected]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The ADD(diff, diff, fs_reg(-2u)) instruction reads diff, which is a
width 1 register. We need to read it as <0,1,0> with a subreg of 0,
which is what smear accomplishes.
Fixes assertion:
brw_eu_emit.c:285: validate_reg: Assertion `hstride == 0' failed.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=86974
Signed-off-by: Kenneth Graunke <[email protected]>
Reviewed-by: Matt Turner <[email protected]>
Cc: [email protected]
|
|
|
|
|
|
|
|
|
|
|
|
| |
These computations don't have anything to do with the currently
executing channels, so they should use force_writemask_all.
This fixes assert failures.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=86974
Signed-off-by: Kenneth Graunke <[email protected]>
Reviewed-by: Matt Turner <[email protected]>
Cc: [email protected]
|
|
|
|
|
|
|
|
|
|
|
| |
Lets define R600_MAX_VIEWPORTS instead of using 16 here and there
in the code when looping through viewports and scissors. It is
easier to understand what this number represents.
v2: Missed a case where R600_MAX_VIEWPORTS should have been used.
Signed-off-by: Alexandre Demers <[email protected]>
Signed-off-by: Marek Olšák <[email protected]>
|
|
|
|
|
|
|
|
| |
Inspired by Damien's recent libdrm changes.
Signed-off-by: Ian Romanick <[email protected]>
Reviewed-by: Damien Lespiau <[email protected]>
Reviewed-by: Jordan Justen <[email protected]>
|
|
|
|
|
|
|
|
| |
Inspired by Damien's recent libdrm changes.
Signed-off-by: Ian Romanick <[email protected]>
Reviewed-by: Damien Lespiau <[email protected]>
Reviewed-by: Jordan Justen <[email protected]>
|
|
|
|
|
|
|
|
| |
Inspired by Damien's recent libdrm changes.
Signed-off-by: Ian Romanick <[email protected]>
Reviewed-by: Damien Lespiau <[email protected]>
Reviewed-by: Jordan Justen <[email protected]>
|
|
|
|
|
|
|
|
|
| |
Since the i915 / i965 split, IS_9XX just means IS_GEN3. Inspired by
Damien's recent libdrm changes.
Signed-off-by: Ian Romanick <[email protected]>
Reviewed-by: Damien Lespiau <[email protected]>
Reviewed-by: Jordan Justen <[email protected]>
|
|
|
|
|
|
|
|
| |
Inspired by Damien's recent libdrm changes.
Signed-off-by: Ian Romanick <[email protected]>
Reviewed-by: Damien Lespiau <[email protected]>
Reviewed-by: Jordan Justen <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Both the AMD and Intel APIs provide a dataSize parameter, and this
function would merrily ignore it. Neither API specifies what to do when
the buffer isn't big enough. I take the easy route of writing all the
complete bits of data that will fit. With more complete specs, we could
probably do something different.
I noticed this while looking into an unused parameter warning. The
warning was actually useful!
brw_performance_monitor.c: In function 'brw_get_perf_monitor_result':
brw_performance_monitor.c:1261:37: warning: unused parameter 'data_size' [-Wunused-parameter]
GLsizei data_size,
^
v2: Fix checks to include offset in the calculation. Noticed by Jan.
Signed-off-by: Ian Romanick <[email protected]>
Reviewed-by: Kenneth Graunke <[email protected]>
Reviewed-by: Jan Vesely <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
All dd functions take a gl_context as the first parameter. Instead of
removing it, just silence the warning.
brw_performance_monitor.c: In function 'brw_new_perf_monitor':
brw_performance_monitor.c:1354:41: warning: unused parameter 'ctx' [-Wunused-parameter]
brw_new_perf_monitor(struct gl_context *ctx)
^
Signed-off-by: Ian Romanick <[email protected]>
Reviewed-by: Carl Worth <[email protected]>
Reviewed-by: Jordan Justen <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
What a useful warning. #ThanksGCC
brw_performance_monitor.c:153:1: warning: 'static' is not at beginning of declaration [-Wold-style-declaration]
const static struct gl_perf_monitor_counter gen5_raw_chaps_counters[] = {
^
brw_performance_monitor.c:185:1: warning: 'static' is not at beginning of declaration [-Wold-style-declaration]
const static int gen5_oa_snapshot_layout[] =
^
brw_performance_monitor.c:221:1: warning: 'static' is not at beginning of declaration [-Wold-style-declaration]
const static struct gl_perf_monitor_group gen5_groups[] = {
^
brw_performance_monitor.c:240:1: warning: 'static' is not at beginning of declaration [-Wold-style-declaration]
const static struct gl_perf_monitor_counter gen6_raw_oa_counters[] = {
^
brw_performance_monitor.c:281:1: warning: 'static' is not at beginning of declaration [-Wold-style-declaration]
const static int gen6_oa_snapshot_layout[] =
^
brw_performance_monitor.c:317:1: warning: 'static' is not at beginning of declaration [-Wold-style-declaration]
const static struct gl_perf_monitor_counter gen6_statistics_counters[] = {
^
brw_performance_monitor.c:332:1: warning: 'static' is not at beginning of declaration [-Wold-style-declaration]
const static int gen6_statistics_register_addresses[] = {
^
brw_performance_monitor.c:346:1: warning: 'static' is not at beginning of declaration [-Wold-style-declaration]
const static struct gl_perf_monitor_group gen6_groups[] = {
^
brw_performance_monitor.c:356:1: warning: 'static' is not at beginning of declaration [-Wold-style-declaration]
const static struct gl_perf_monitor_counter gen7_raw_oa_counters[] = {
^
brw_performance_monitor.c:402:1: warning: 'static' is not at beginning of declaration [-Wold-style-declaration]
const static int gen7_oa_snapshot_layout[] =
^
brw_performance_monitor.c:470:1: warning: 'static' is not at beginning of declaration [-Wold-style-declaration]
const static struct gl_perf_monitor_counter gen7_statistics_counters[] = {
^
brw_performance_monitor.c:493:1: warning: 'static' is not at beginning of declaration [-Wold-style-declaration]
const static int gen7_statistics_register_addresses[] = {
^
brw_performance_monitor.c:515:1: warning: 'static' is not at beginning of declaration [-Wold-style-declaration]
const static struct gl_perf_monitor_group gen7_groups[] = {
^
Signed-off-by: Ian Romanick <[email protected]>
Reviewed-by: Carl Worth <[email protected]>
Reviewed-by: Jordan Justen <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
| |
I don't this opt_cmod_propagation_local ever used the fs_visitor.
brw_fs_cmod_propagation.cpp:52:40: warning: unused parameter 'v' [-Wunused-parameter]
opt_cmod_propagation_local(fs_visitor *v, bblock_t *block)
^
Signed-off-by: Ian Romanick <[email protected]>
Reviewed-by: Matt Turner <[email protected]>
Reviewed-by: Jordan Justen <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
| |
Unused since b18fd23.
brw_fs.cpp:2878:44: warning: unused parameter 'dispatch_width' [-Wunused-parameter]
clear_deps_for_inst_src(fs_inst *inst, int dispatch_width, bool *deps,
^
Signed-off-by: Ian Romanick <[email protected]>
Reviewed-by: Jason Ekstrand <[email protected]>
Reviewed-by: Jordan Justen <[email protected]>
|
|
|
|
|
|
|
|
|
| |
brw_fs_visitor.cpp:2162:56: warning: unused parameter 'offset_components' [-Wunused-parameter]
fs_reg offset_value, unsigned offset_components,
^
Signed-off-by: Ian Romanick <[email protected]>
Reviewed-by: Jordan Justen <[email protected]>
|
|
|
|
|
|
|
|
| |
v2: Review by Martin Peres
- Get rid of difficult-to-follow code copied and pasted from
the original TexBufferRange
Reviewed-by: Anuj Phogat <[email protected]>
|
|
|
|
|
|
|
|
|
|
| |
Creates a shared function to ensure that texture buffer target is
GL_TEXTURE_BUFFER. Helps to clean up the Tex[ture]Buffer[Range] functions.
v2: Review from Anuj Phogat
- Split rebase of Tex[ture]Buffer[Range]
Reviewed-by: Anuj Phogat <[email protected]>
|
|
|
|
|
|
|
|
|
|
| |
Creates a shared function that TexBufferRange and TextureBufferRange can use
to check the buffer range. This cleans up TexBufferRange considerably.
v2: Review from Anuj Phogat
- Split rebase of Tex[ture]Buffer[Range]
Reviewed-by: Anuj Phogat <[email protected]>
|
|
|
|
|
|
|
|
|
| |
Adds a useful comment and some whitespace. Fixes an error message.
v2: Review from Anuj Phogat
- Split rebase of Tex[ture]Buffer[Range]
Reviewed-by: Anuj Phogat <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
| |
Changes how the caller is identified in error messages, moves a check for
ARB_texture_buffer_object from the entry points to the shared code in
_mesa_texture_buffer_range, and removes an unused argument (GLenum target).
v2: Review from Anuj Phogat
- Split rebase of Tex[ture]Buffer[Range]
Reviewed-by: Anuj Phogat <[email protected]>
|
|
|
|
|
|
|
|
| |
v2: Review from Anuj Phogat
- Split rebase of Tex[ture]Buffer[Range]
- Closing curly brace on the same line as else
Reviewed-by: Anuj Phogat <[email protected]>
|
|
|
|
|
|
|
| |
This function is exposed to mesa driver internals so that texture buffer
objects and array objects can use it.
Reviewed-by: Anuj Phogat <[email protected]>
|
|
|
|
|
|
|
|
|
| |
v2: Review from Anuj Phogat
- Remove redundant copies of the cube map block comment
- Replace redundant "if (!texImage) return;" statements with
assert(texImage)
Reviewed-by: Anuj Phogat <[email protected]>
|
|
|
|
|
|
|
|
|
| |
v2: Review from Anuj Phogat
- Remove redundant copies of the cube map block comment
- Replace redundant "if (!texImage) return;" statements with
assert(texImage)
Reviewed-by: Anuj Phogat <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
ARB_direct_state_access functions that deal with texture cube
maps need to make sure that texture images are not NULL before operating on
them. In the following cases, the error check functions already throw an
error if texImage == NULL, so an assert can be raised instead.
v2: Review from Anuj Phogat
- Replace redundant "if (!texImage) return;" statements with
assert(texImage)
Reviewed-by: Anuj Phogat <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
| |
The comment describing why ARB_direct_state_access texture cube map functions
use _mesa_cube_level_complete is very long. To save room in the files,
readers are now referred to one central comment on texturesubimage in
teximage.c.
v2: Review from Anuj Phogat
- Remove redundant copies of the cube map block comment
Reviewed-by: Anuj Phogat <[email protected]>
|
|
|
|
|
|
|
|
| |
ARB_direct_state_access texture functions that operate on cube maps no longer
need to verify that cube map texture objects contain six texture images
because _mesa_cube_level_complete now does that for them.
Reviewed-by: Anuj Phogat <[email protected]>
|
|
|
|
|
|
|
| |
_mesa_cube_level_complete now verifies that a cube map texture object actually
has six texture images before proceeding.
Reviewed-by: Anuj Phogat <[email protected]>
|
|
|
|
| |
Cc: 10.5 10.4 <[email protected]>
|