| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
| |
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]>
|
|
|
|
|
|
|
| |
State upload code should use prog_data rather than poking at shader_info
directly.
Reviewed-by: Topi Pohjolainen <[email protected]>
|
|
|
|
|
|
| |
Less baklava layers.
Reviewed-by: Topi Pohjolainen <[email protected]>
|
|
|
|
|
|
|
| |
We either want the framebuffer dimensions or 1x1x1. Passing fb and
falling back to 1x1x1 lets us shorten some calls.
Reviewed-by: Topi Pohjolainen <[email protected]>
|
|
|
|
|
|
| |
Replace piles of my own boilerplate with 1-2 lines of code.
Reviewed-by: Topi Pohjolainen <[email protected]>
|
|
|
|
|
|
|
|
|
| |
We don't need yet another set of flags. The function already has access
to both brw and the unit, so it can check brw->draw_aux_buffer_disabled
itself in one line of code. The layered flag was only used to assert
that Gen4-5 doesn't do layered rendering, which isn't that useful.
Reviewed-by: Topi Pohjolainen <[email protected]>
|
|
|
|
|
|
|
|
| |
Also rename it to gen6_update_renderbuffer_surface, as this is the
function for Gen6+. Having functions named "brw_*" and "gen4_*"
is confusing...if we're using gens, let's stick with those.
Reviewed-by: Topi Pohjolainen <[email protected]>
|