| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
| |
Signed-off-by: Eric Engestrom <[email protected]>
Reviewed-by: Ian Romanick <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When a batch is submitted, INTEL_DEBUG=bat prints a message indicating
which part of the code triggered the flush, and some statistics about
the batch/state buffer utilization.
It also decodes the batchbuffer in debug builds...which is so much
output that it drowns out the utilization messages, if that's all you
care about.
INTEL_DEBUG=submit now just does the utilization messages.
INTEL_DEBUG=bat continues to do both (as the message is a good indicator
that we're starting decode of a new batch).
v2: Rename from "flush" to "submit" (suggested by Chris) because we
might want "flush" for PIPE_CONTROL debugging someday.
Reviewed-by: Chris Wilson <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We were skipping this fallback for depth, but not for stencil
which the hardware always requires to be W-tiled.
Also, make the checks for whether we need to apply retiling
strategies based on usage instead of tiling flags, which is
safer and more explicit.
This fixes a regression in a CTS test introduced with commit
4ea63fab77f0 that started applying re-tiling stencil surfaces
in certain scenarios.
v2: discard retiling based on usage fields instead of tiling
flags. This is safer and more explicit.
v3: Add a comment indicating that texturing of stencil in gen7
requires an Y-tiled copy (Topi).
Fixes:
KHR-GL45.direct_state_access.renderbuffers_storage
Reviewed-by: Topi Pohjolainen <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
| |
src/mesa/drivers/dri/i965/intel_tex.h:52:40: warning: ‘enum intel_miptree_create_flags’ declared inside parameter list will not be visible outside of this definition or declaration
enum intel_miptree_create_flags flags);
^~~~~~~~~~~~~~~~~~~~~~~~~~
Fixes: cadcd89278edcda8aba2 "i965/tex: Change the flags type on
create_for_teximage"
Signed-off-by: Eric Engestrom <[email protected]>
Reviewed-by: Jason Ekstrand <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
| |
We don't need to special case the batch - when we add the batch to the
validation list, we can simply increase the refcount to 2, and when we
make a new batch, we'll drop it back down to 1 (when unreferencing all
buffers in the validation list). The final reference is still held by
brw->batch.bo, as it was before.
This removes the special case from a bunch of loops.
Reviewed-by: Chris Wilson <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
As Marek pointed out in earlier commit - exposing RGBA on other
platforms introduces ~500 Visuals, which are not tested.
Note that this does not quite happen, yet. Reason being that the GLX
code does not check the masks - see scaralEqual().
Thus as we fix that, we'll run into the issue described.
v2: Rebase, while keeping loaderPrivate
v3: Beef-up commit message, getCapability() returns unsigned (Tapani)
Fixes: 1bf703e4ea5 ("dri_interface,egl,gallium: only expose RGBA visuals
on Android")
Cc: Tomasz Figa <[email protected]>
Cc: Chad Versace <[email protected]>
Cc: Marek Olšák <[email protected]>
Signed-off-by: Emil Velikov <[email protected]>
Reviewed-by: Tapani Pälli <[email protected]>
|
|
|
|
| |
Reviewed-by: Jason Ekstrand <[email protected]>
|
|
|
|
|
|
| |
One less layer of baklava.
Reviewed-by: Jason Ekstrand <[email protected]>
|
|
|
|
|
|
|
| |
We can't perf_debug without a context.
Cc: [email protected]
Reviewed-by: Anuj Phogat <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
It doesn't seem like the old code could possibly work.
1. brw_gs_state_dirty made us bail unless one of these flags were set:
_NEW_TEXTURE, BRW_NEW_GEOMETRY_PROGRAM, BRW_NEW_TRANSFORM_FEEDBACK
2. If there was no geometry program, we called brw_upload_ff_gs_prog()3
3. That checked brw_ff_gs_state_dirty and bailed unless these were set:
_NEW_LIGHT, BRW_NEW_PRIMITIVE, BRW_NEW_TRANSFORM_FEEDBACK,
BRW_NEW_VS_PROG_DATA.
4. brw_ff_gs_prog_key pv_first and attr fields were set based on data
depending on _NEW_LIGHT and BRW_NEW_VS_PROG_DATA.
This means that if we needed a FF GS program, and changed the VS
outputs or provoking vertex mode, we'd fail to notice that we needed
to emit a new program.
Reviewed-by: Jordan Justen <[email protected]>
|
|
|
|
|
|
| |
gen6...brw? Drop some baklava layers.
Reviewed-by: Jordan Justen <[email protected]>
|
|
|
|
|
|
| |
It's only used in one file.
Reviewed-by: Chris Wilson <[email protected]>
|
|
|
|
|
|
| |
This is dead code and hasn't been used in a long time.
Reviewed-by: Chris Wilson <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We can drop the meaningless "64" suffix - libdrm_intel originally had
an "offset" field that was an "unsigned long" which was the wrong size,
and we couldn't remove/alter that field without breaking ABI, so we had
to add a uint64_t "offset64" field.
"gtt_offset" is also more descriptive than "offset".
(Patch originally written by Ken, but Chris suggested a better name and
supplied the giant comment making up the bulk of the patch, so I changed
the authorship to him.)
Acked-by: Kenneth Graunke <[email protected]>
Reviewed-by: Chris Wilson <[email protected]>
|
|
|
|
|
|
|
| |
It's used in exactly one place these days, and not much simpler than
just calling intel_batchbuffer_data directly.
Reviewed-by: Chris Wilson <[email protected]>
|
|
|
|
|
|
|
|
|
| |
intel_batchbuffer_reset calls add_exec_bo on the batch right away,
which adds in the batch BO size.
Fixes: 29ba502a4e28 ("i965: Use I915_EXEC_BATCH_FIRST when available.")
Reviewed-by: Chris Wilson <[email protected]>
|
|
|
|
|
|
|
|
| |
Improves performance of GFXBench4 tests at 1024x768 on a Kabylake GT2:
- Manhattan 3.1 by 1.32134% +/- 0.322734% (n=8).
- Car Chase by 1.25607% +/- 0.291262% (n=5).
Reviewed-by: Jason Ekstrand <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When we blit data into a buffer object, we may need to invalidate any
caches that might contain stale data, so the new data becomes visible.
For example, if the buffer object is bound as a vertex buffer, we need
to invalidate the vertex fetch cache.
While this flushing was missing, it usually happened implicitly for
non-obvious reasons: we're usually on the render ring, and calling
intel_emit_linear_blit() would require switching to the BLT ring,
causing an implicit flush. This likely provoked the kernel to do
PIPE_CONTROLs on our behalf. Although, Gen4-5 wouldn't have this
behavior. At any rate, we should do it ourselves.
Reviewed-by: Jason Ekstrand <[email protected]>
|
|
|
|
|
|
|
|
|
| |
Although we're phasing out brw_emit_mi_flush(), we still use it in some
places in order to "flush everything". In a number of those places, we
write data to a buffer that we may then bind as an image surface, SSBO,
or atomic buffer. Those usages require us to flush the data cache.
Reviewed-by: Jason Ekstrand <[email protected]>
|
|
|
|
|
|
|
|
| |
This exposes the new blorp_copy_buffer() functionality to i965.
It should be a drop-in replacement for intel_emit_linear_blit()
(other than the arguments being backwards, for consistency with BLORP).
Reviewed-by: Jason Ekstrand <[email protected]>
|
|
|
|
|
|
| |
Signed-off-by: Lionel Landwerlin <[email protected]>
Reviewed-by: Samuel Iglesias Gonsálvez <[email protected]>
Reviewed-by: Emil Velikov <[email protected]>
|
|
|
|
|
|
| |
Signed-off-by: Lionel Landwerlin <[email protected]>
Reviewed-by: Samuel Iglesias Gonsálvez <[email protected]>
Reviewed-by: Emil Velikov <[email protected]>
|
|
|
|
|
|
| |
Signed-off-by: Lionel Landwerlin <[email protected]>
Reviewed-by: Samuel Iglesias Gonsálvez <[email protected]>
Reviewed-by: Emil Velikov <[email protected]>
|
|
|
|
|
|
| |
Signed-off-by: Lionel Landwerlin <[email protected]>
Reviewed-by: Samuel Iglesias Gonsálvez <[email protected]>
Reviewed-by: Emil Velikov <[email protected]>
|
|
|
|
|
|
| |
Signed-off-by: Lionel Landwerlin <[email protected]>
Reviewed-by: Samuel Iglesias Gonsálvez <[email protected]>
Reviewed-by: Emil Velikov <[email protected]>
|
|
|
|
|
|
| |
Signed-off-by: Lionel Landwerlin <[email protected]>
Reviewed-by: Samuel Iglesias Gonsálvez <[email protected]>
Reviewed-by: Emil Velikov <[email protected]>
|
|
|
|
|
|
| |
Signed-off-by: Lionel Landwerlin <[email protected]>
Reviewed-by: Samuel Iglesias Gonsálvez <[email protected]>
Reviewed-by: Emil Velikov <[email protected]>
|
|
|
|
|
|
| |
Signed-off-by: Lionel Landwerlin <[email protected]>
Reviewed-by: Samuel Iglesias Gonsálvez <[email protected]>
Reviewed-by: Emil Velikov <[email protected]>
|
|
|
|
|
|
|
|
|
| |
We need to take some take here as brw->is_broxton has been used to
check whether the device is a low power gen9 (aka Atom gen9 platform).
Signed-off-by: Lionel Landwerlin <[email protected]>
Reviewed-by: Samuel Iglesias Gonsálvez <[email protected]>
Reviewed-by: Emil Velikov <[email protected]>
|
|
|
|
|
|
| |
Signed-off-by: Lionel Landwerlin <[email protected]>
Reviewed-by: Samuel Iglesias Gonsálvez <[email protected]>
Reviewed-by: Emil Velikov <[email protected]>
|
|
|
|
|
|
| |
Signed-off-by: Lionel Landwerlin <[email protected]>
Reviewed-by: Samuel Iglesias Gonsálvez <[email protected]>
Reviewed-by: Emil Velikov <[email protected]>
|
|
|
|
|
|
| |
Signed-off-by: Lionel Landwerlin <[email protected]>
Reviewed-by: Samuel Iglesias Gonsálvez <[email protected]>
Reviewed-by: Emil Velikov <[email protected]>
|
|
|
|
|
|
| |
Signed-off-by: Lionel Landwerlin <[email protected]>
Reviewed-by: Samuel Iglesias Gonsálvez <[email protected]>
Reviewed-by: Emil Velikov <[email protected]>
|
|
|
|
|
|
| |
Signed-off-by: Lionel Landwerlin <[email protected]>
Reviewed-by: Samuel Iglesias Gonsálvez <[email protected]>
Reviewed-by: Emil Velikov <[email protected]>
|
|
|
|
|
|
| |
Signed-off-by: Lionel Landwerlin <[email protected]>
Reviewed-by: Samuel Iglesias Gonsálvez <[email protected]>
Reviewed-by: Emil Velikov <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
| |
For Gen8, add 2xMSAA. For Gen9, add 2xMSAA and 16xMSAA.
Special thanks to Eero Tamminen for reporting rasterizer
numbers being twice what it should be for 2xMSAA under
a benchmark.
V2: Make pointer name less ugly + add 2xMSAA for Gen8
Reviewed-by: Kenneth Graunke <[email protected]>
|
|
|
|
|
|
|
|
|
| |
This reverts commit f6d38785e8b28a6dd303884798b823e289817741.
Kevin's original patch accidentally didn't add 2x for Gen8; he sent
a v2 with a bunch of style fixes shortly after I pushed the original
patch, not knowing it was coming. Let's just revert this one, apply
v2, and move on.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Our initial size of 4kB is way too small to do anything useful, so we
end up growing it at least a few times. We may as well start it larger.
Some data points:
- Dinoshade (from Mesa Demos): hit 8kB.
- Chromium 60: hit 16kB after browsing a few things in Google Docs.
- GFXBench4 TRex/Manhattan 3.1: hit 128kB
- Unigine Valley 1.0: hit 512kB
It might make sense to start it even larger.
Acked-by: Matt Turner <[email protected]>
|
|
|
|
|
|
|
| |
This involves a bunch of unnecessary copying, a batch flush, and
state re-emission.
Reviewed-by: Matt Turner <[email protected]>
|
|
|
|
|
|
|
|
|
| |
Special thanks to Eero Tamminen for reporting rasterizer
numbers being twice what it should be for 2xMSAA under
a benchmark.
Signed-off-by: Kevin Rogovin <[email protected]>
Reviewed-by: Kenneth Graunke <[email protected]>
|
|
|
|
|
|
|
|
| |
brw_surface_formats.c and genX_blorp_exec.c do this a lot, causing lots
of warnings from clang.
Reviewed-by: Emil Velikov <[email protected]>
Reviewed-by: Eric Engestrom <[email protected]>
|
|
|
|
|
|
|
|
| |
The functions we're marking as UNUSED in genX_state_upload.c are used
only when compiling for particular generations.
Reviewed-by: Emil Velikov <[email protected]>
Reviewed-by: Eric Engestrom <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Fixes warnings like
warning: implicit conversion from enumeration type 'enum isl_format' to
different enumeration type 'enum GEN10_SURFACE_FORMAT'
[-Wenum-conversion]
.SourceElementFormat = ISL_FORMAT_R32_UINT,
^~~~~~~~~~~~~~~~~~~
Reviewed-by: Emil Velikov <[email protected]>
Reviewed-by: Eric Engestrom <[email protected]>
|
|
|
|
|
|
|
|
|
| |
brw_texture_view_sane() is only used by an assert()...
No difference in the resulting binary with gcc-6.3.0 or clang-4.0.
Reviewed-by: Emil Velikov <[email protected]>
Reviewed-by: Eric Engestrom <[email protected]>
|
|
|
|
| |
Convert tabs to spaces and rewrap one long line.
|
|
|
|
|
|
|
|
| |
We were using brw->gen, brw->is_haswell, and devinfo->gen in a few
places, when we could just use GEN_GEN and GEN_IS_HASWELL, which are
evaluated at compile time.
Reviewed-by: Eduardo Lima Mitev <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
| |
Semantically identical to the EXT version (whose string is still valid
for GLES), so rename the bit but expose both extension strings.
(Suggested by Ilia Mirkin and Ian Romanick.)
v3: Fix the entrypoint alias in GL4x.xml (Ilia)
Signed-off-by: Adam Jackson <[email protected]>
Reviewed-by: Ilia Mirkin <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
| |
The only difference from the EXT version is bumping the minmax to 16, so
just hit all the drivers at once.
v2: Fix driver names, add to 17.3 release notes (Ilia Mirkin)
Reviewed-by: Ilia Mirkin <[email protected]>
Signed-off-by: Adam Jackson <[email protected]>
Reviewed-by: Kenneth Graunke <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Gets rid of a few warnings of the form:
src/mesa/drivers/dri/i965/intel_screen.c:918:49: warning: passing argument 2 of ‘modifier_is_supported’ discards ‘const’ qualifier from pointer target type [-Wdiscarded-qualifiers]
!modifier_is_supported(&screen->devinfo, f, 0, modifier))
^
src/mesa/drivers/dri/i965/intel_screen.c:301:1: note: expected ‘struct intel_image_format *’ but argument is of type ‘const struct intel_image_format *’
Fixes: 1efd73df39b39589d26f "i965: Advertise the CCS modifier"
Cc: Ben Widawsky <[email protected]>
Signed-off-by: Eric Engestrom <[email protected]>
Reviewed-by: Matt Turner <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Render target surfaces always start at binding table index 0.
This is required for us to use headerless FB writes, which we
really want to do. So, we'll never change that.
Given that, it's not necessary to look up a wm_prog_data field
which we already know contains 0. We can drop the dependency in
brw_renderbuffer_surfaces (Gen4-5)...which was already confusingly
missing from gen6_renderbuffer_surfaces.
Reviewed-by: Topi Pohjolainen <[email protected]>
|