| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
| |
The implementation of brw_miptree_layout was removed in bf24c3539e4b69.
Reviewed-by: Jordan Justen <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
| |
Originally, I had moved it to the caller to make some things easier when
adding the CCS modifier. However, this broke DRI2 because
intel_process_dri2_buffer calls intel_miptree_create_for_bo but never
calls intel_miptree_alloc_aux. Also, in hindsight, it should be pretty
easy to make the CCS modifier stuff work even if create_for_bo allocates
the CCS when DISABLE_AUX is not set.
Reviewed-by: Jordan Justen <[email protected]>
Cc: "17.2" <[email protected]>
|
|
|
|
|
|
|
|
|
| |
The flag hasn't affected actual surface layout for some time. The only
purpose it served was to set bo->cache_coherent = false on the BO used
to create the miptree. This is fairly silly because we can just set
that directly from the caller where it makes much more sense.
Reviewed-by: Jordan Justen <[email protected]>
|
|
|
|
| |
Reviewed-by: Jordan Justen <[email protected]>
|
|
|
|
|
|
|
|
|
| |
We rename it to intel_miptree_supports_mcs and make the function
signature match intel_miptree_supports_ccs/hiz. We also move the sample
count check into the function so it returns false for single-sampled
surfaces.
Reviewed-by: Jordan Justen <[email protected]>
|
|
|
|
|
|
|
| |
The one caller of is_mcs_supported passes 0 in as the layout_flags
unconditionally.
Reviewed-by: Jordan Justen <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The kernel only cares about whether the object is to be written to or
not, only reduces (reloc.read_domains, reloc.write_domain) down to just
!!reloc.write_domain. When we use NO_RELOC, the kernel doesn't even read
those relocs and instead userspace has to pass that information in the
execobject.flags. We can simplify our reloc api by also removing the
unused read/write domains and only pass the resultant flags.
The caveat to the above are when we need to make the kernel aware that
certain objects need to take into account different work arounds.
Previously, this was done using the magic (INSTRUCTION, INSTRUCTION)
reloc domains. NO_RELOC requires this to be passed in the execobject
flags as well, and now we push that up the callstack.
The API is more compact, more expressive of what happens underneath, but
unfortunately requires more knowledge of the system at the point of use.
Conversely it also means that knowledge is specific and not generally
applied and so not overused.
text data bss dec hex filename
8502991 356912 424944 9284847 8dacef lib/i965_dri.so (before)
8500455 356912 424944 9282311 8da307 lib/i965_dri.so (after)
v2: (by Ken) Rebase.
Reviewed-by: Kenneth Graunke <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Based on a patch by Chris Wilson (who also wrote this commit message).
Passing the index of the target buffer via the reloc.target_handle is
marginally more efficient for the kernel (it can avoid some allocations,
and can use a direct lookup rather than a hash or search). It is also
useful for ourselves as we can use the index into our exec_bos for other
tasks.
v2: Only enable HANDLE_LUT if we can use BATCH_FIRST and thereby avoid
a post-processing loop to fixup the relocations.
v3: Move kernel probing from context creation to screen init.
Use batch->use_exec_lut as it more descriptive of what's going on (Daniel)
v4: Kernel features already exists, use it for BATCH_FIRST
Rename locals to preserve current flavouring
v5: Squash in "always insert batch bo first"
v6: (by Ken) Split out BATCH_FIRST from HANDLE_LUT.
|
|
|
|
|
|
| |
More succinct - we can skip a bunch of = 0 lines.
Extracted from a patch by Chris Wilson.
|
|
|
|
|
|
|
|
| |
Extracted from a patch by Chris Wilson.
Now that the batch is always at the front of the validation list,
we don't need to special case it - the usual "go find an existing BO"
code will work just fine.
|
|
|
|
|
|
| |
This will make it easier to use I915_EXEC_HANDLE_LUT.
Based on a patch by Chris Wilson.
|
|
|
|
|
|
|
|
|
|
| |
To avoid a forward declaration in the next patch, move the definition of
add_exec_bo() earlier.
v2: (by Ken) redo move.
Signed-off-by: Chris Wilson <[email protected]>
Reviewed-by: Kenneth Graunke <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Since before the kernel supported I915_EXEC_NO_RELOC, long before our
minimum kernel requirement, the kernel unconditionally invalidated all
GPU TLBs before a batch and flushed all GPU caches after a batch. At
that moment, the only use for read/write domain was for activity
tracking, ensuring that future reads waited for the last writer and
future writes waited for all reads. This only requires a single bit in
the execbuf interface which can be supplied via the NO_RELOC interface,
making the use of relocation domains entirely redundant.
Trimming the excess writes into the array allows the compiler to be much
more frugal:
text data bss dec hex filename
8493790 357184 424944 9275918 8d8a0e i965_dri.baseline
8493758 357184 424944 9275886 8d89ee i965_dri.so
(This text improvement really does come from dropping domains, not from
the new use of C99 initializers.)
Signed-off-by: Chris Wilson <[email protected]>
Reviewed-by: Kenneth Graunke <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
| |
If we correctly fill the batch with the right relocation value, and that
matches the expected location of the object, we can then tell the kernel
it can forgo checking each individual relocation by only checking
whether the object moved.
v2: Rebase to apply ahead of I915_EXEC_HANDLE_LUT
Signed-off-by: Chris Wilson <[email protected]>
Reviewed-by: Kenneth Graunke <[email protected]>
|
|
|
|
| |
This makes it a bit easier to add new unconditional flags.
|
|
|
|
| |
This will be useful for I915_EXEC_HANDLE_LUT and I915_EXEC_NO_RELOC.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Borrow a trick from anv, and use the last known index for the bo to skip
a search of the batch->exec_bo when adding a new relocation. In defence
against the bo being used in multiple batches simultaneously, we check
that this slot exists and points back to us.
v2: Also update brw_batch_references()
v3: Reset bo->index on creation (Daniel)
v4: Improved explanation of bo->index (Kenneth)
Signed-off-by: Chris Wilson <[email protected]>
Reviewed-by: Kenneth Graunke <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We must be careful to only compute the address once based on the
per-context information (rather than accessing the unlocked global
bo->offset64) so that the value in the batch does match the
reloc.presumed_offset we declare to the kernel. Otherwise, highly
unlikely, but we may see GPU hangs in multithreaded users.
The only real complication here is isl_surf_fill_state() which needs to
adjust the reloc.delta to both general a tile offset and to encode state
into the lower 12 bits.
(Rebased on ISL changes by Ken.)
Reviewed-by: Kenneth Graunke <[email protected]>
|
|
|
|
|
|
| |
You need an actual BO to emit a relocation to it.
Suggested by me, authored by Chris, split out of a larger patch.
|
|
|
|
|
|
|
|
|
|
| |
For buffer objects, where we primarily expect to be writing to them and
so already have a WC mmap (for !llc access) reusing the existing mmap
and keeping the buffer out of the CPU cache seems preferable.
Cc: Kenneth Graunke <[email protected]>
Cc: Matt Turner <[email protected]>
Reviewed-by: Matt Turner <[email protected]>
|
|
|
|
|
|
|
|
| |
These were only here to keep building without needing to update libdrm.
Now that we include i915_drm.h in Mesa, we don't need this - our copy
is new enough and has the #define.
Trivial.
|
|
|
|
|
|
|
|
| |
Remember to add the offset to the start of the buffer in the relocation
or else we write 0xff into random bytes elsewhere.
Reviewed-by: Kenneth Graunke <[email protected]>
Cc: [email protected]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
As of 4.11, the kernel isn't bothering to set the subslice hashing mode
on Apollolake, leaving it at the default of 8x8. (It initializes it to
16x4 on most platforms.)
Performance data for GPUTest Triangle on Apollolake at 1024x640:
X-tiled RT:
-----------
8x8 -> 16x4: 2.4325% +/- 0.383683% (n=107)
8x8 -> 8x4: -3.75105% +/- 0.592491% (n=40)
8x8 -> 16x16: 6.17238% +/- 0.67157% (n=30)
Y-tiled RT:
-----------
8x8 -> 16x4: 1.30307% +/- 0.297292% (n=205)
8x8 -> 8x4: -0.769282% +/- 0.729557% (n=35)
8x8 -> 16x16: 3.00254% +/- 0.715503% (n=40)
8x MSAA RT (INTEL_FORCE_MSAA=8):
--------------------------------
8x8 -> 16x4: 1.38889% +/- 0.93729% (n=7)
8x8 -> 8x4: -2.10643% +/- 1.15153% (n=3)
8x8 -> 16x16: 3.87183% +/- 1.08851% (n=5)
Based on this, we choose 16x16 for Apollolake.
Skylake GT2 with X-tiled buffers appears to be a toss-up between 16x4
and 16x16, and with Y-tiled buffers it doesn't seem to really matter.
So we'll leave Skylake alone for now.
The hashing mode doesn't seem to make a measurable impact on more
complex benchmarks.
Acked-by: Matt Turner <[email protected]>
|
|
|
|
|
|
|
|
| |
This isn't used in any of these drivers.
Reviewed-by: Marek Olšák <[email protected]>
Reviewed-by: Emil Velikov <[email protected]>
Signed-off-by: Dave Airlie <[email protected]>
|
|
|
|
|
|
|
| |
Drop the local variable and return directly.
Signed-off-by: Emil Velikov <[email protected]>
Reviewed-by: Matt Turner <[email protected]>
|
|
|
|
|
|
|
| |
Already used as such througout the code.
Signed-off-by: Emil Velikov <[email protected]>
Reviewed-by: Matt Turner <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The cacheline alignment restriction is on the base address; the pitch
can be anything.
Fixes assertion failures when using primus (say, on glxgears, which
creates a 300x300 linear BGRX surface with a pitch of 1200):
intel_blit.c:190: get_blit_intratile_offset_el: Assertion `mt->surf.row_pitch % 64 == 0' failed.
Cc: [email protected]
Reviewed-by: Chris Wilson <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Fixes following build issues:
In file included from vendor/intel/external/android_ia/mesa/src/mesa/drivers/dri/common/dri_util.c:45:
vendor/intel/external/android_ia/mesa/src/util/xmlpool.h:103:10: fatal error: 'xmlpool/options.h' file not found
...
In file included from vendor/intel/external/android_ia/mesa/src/mesa/drivers/dri/i965/intel_screen.c:44:
vendor/intel/external/android_ia/mesa/src/util/xmlpool.h:103:10: fatal error: 'xmlpool/options.h' file not found
Fixes: 601093f9 (xmlconfig: move into src/util)
Signed-off-by: Tapani Pälli <[email protected]>
Reviewed-by: Chih-Wei Huang <[email protected]>
|
|
|
|
|
|
|
| |
Since make_surface() can fail, if the format isn't support by hw or
simlar error, we need to check the result before dereferencing it.
Reviewed-by: Kenneth Graunke <[email protected]>
|
|
|
|
|
|
| |
Fixes: 601093f95ddf ("xmlconfig: move into src/util")
Tested-by: Eric Engestrom <[email protected]>
Tested-by: Roland Scheidegger <[email protected]>
|
|
|
|
|
|
|
|
|
|
| |
It's a single atomic add, so it makes sense to inline it.
Improves performance in Piglit's drawoverhead microbenchmark's
"DrawArrays ( 1 VBO, 0 UBO, 0 ) w/ no state change" subtest by
0.400922% +/- 0.310389% (n=350) on my i7-7700HQ.
Reviewed-by: Jason Ekstrand <[email protected]>
|
|
|
|
|
|
|
|
| |
v2: attempt to fix Android build (Emil)
v3: add missing include path
Reviewed-by: Marek Olšák <[email protected]> (v1)
|
|
|
|
| |
Reviewed-by: Marek Olšák <[email protected]>
|
|
|
|
|
|
|
|
| |
In commit 877128505431adaf817dc8069172ebe4a1cdf5d8, José replaced the
Tungsten Graphics copyright notices with VMware, as Tungsten is gone.
I later imported brw_bufmgr.c, reintroducing a Tungsten copyright.
This commit does the equivalent of José's change to the new file.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This reformats the copyright header to match what we use in most of the
newer parts of the driver. There are a few minor alterations: we change
"COPYRIGHT HOLDERS, AUTHORS AND/OR ITS SUPPLIERS" to the standard
"AUTHORS OR COPYRIGHT HOLDERS", and move the permission notice to the
proper place (it should be in the middle, so "next paragraph" actually
refers to something).
Both of these changes match the OSI's MIT License text:
https://opensource.org/licenses/MIT
I copied this from genX_state_upload.c.
|
|
|
|
|
|
|
| |
This reverts commit a7617a49fbde2fcfccdab22886aeabdbf8abb8e4.
glthread disables itself automatically and therefore has no effect
on the game.
|
|
|
|
|
|
|
| |
This is useless.
Signed-off-by: Samuel Pitoiset <[email protected]>
Reviewed-by: Marek Olšák <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We already have this little optimization for color clears. Now that
we're actually tracking whether or not a slice has any fast-clear
blocks, it's easy enough to add for depth clears too.
Improves performance of GFXBench 4 TRex at 1920x1080 by:
- Skylake GT4: 0.905932% +/- 0.0620197% (n = 30)
- Apollolake: 0.382434% +/- 0.1134730% (n = 25)
v2: (by Ken) Rebase and drop intel_mipmap_tree.c changes, as they're
no longer necessary (other patches already landed to do that part)
Reviewed-by: Kenneth Graunke <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When changing the clear value, we need to resolve any fast cleared data.
Previously, we were performing resolves on every slice with HiZ enabled.
We only need to resolve slices that a) have fast clear data, and b)
aren't about to be cleared to the new color. In the latter case, we
were actually doing a resolve, and then a fast clear - when we could
skip both, causing the existing fast cleared area to be updated to the
new clear value for no additional work.
This patch stops using intel_miptree_prepare_access in favor of a more
optimal open coded loop that knows about our clear operation.
v2: (by Ken) Rebase on islification, write a real commit message.
Reviewed-by: Kenneth Graunke <[email protected]>
Reviewed-by: Lionel Landwerlin <[email protected]>
|
|
|
|
|
|
| |
I want to use it in brw_clear.c.
Reviewed-by: Lionel Landwerlin <[email protected]>
|
|
|
|
|
| |
From 25-26 min fps to 31, used the game in conjuction with a mod (full
invasion 2) beaumaris castle map and 200 bots.
|
|
|
|
|
|
|
|
| |
Here the AUX_USAGE_* mode indicates that we have HiZ, so we will have
a HiZ buffer. But Coverity doesn't know that, so it thinks it might
be NULL because we checked hiz_buf != NULL earlier.
Reviewed-by: Jason Ekstrand <[email protected]>
|
|
|
|
|
|
|
| |
Caught by Coverity (CID 1415680).
Cc: "17.2" <[email protected]>
Reviewed-by: Jason Ekstrand <[email protected]>
|
|
|
|
|
|
|
|
|
| |
Increase the value, not the pointer to the stack variable.
Caught by Coverity (CID 1415574). Not shipped in a real release.
Cc: "17.2" <[email protected]>
Reviewed-by: Topi Pohjolainen <[email protected]>
|
|
|
|
|
|
|
|
|
| |
Performance delta on Core i5-4570 + Radeon R9 270:
Overlord: +20% in certain locations
Overlord II: +20% in certain locations
Oil Rush: +12% in most locations
War Thunder: +4-9% in benchmarks
Saints Row 2: +10-35% in certain locations
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
As Chris commented, it makes more sense to have batch buffer flushes
before the query. Usually applications like frame_retrace do a series
of queries and in that case, with flushes at the end of the queries,
we might still have the first query contained in 2 different batchs.
More generally it would be quite usual to have the query contained in
2 batch buffers because we never now what's the fill rate of the
current batch buffer.
If we move the flushing at the beginning of the queries, it's pretty
much guaranteed that queries will be contained in a single batch
buffer (unless the amount of commands is huge, but then it's only fair
to include reloading request times in the measurements).
Fixes: adafe4b733c02 ("i965: perf: minimize the chances to spread queries across batchbuffers")
Reported-by: Chris Wilson <[email protected]>
Signed-off-by: Lionel Landwerlin <[email protected]>
Cc: "17.2 17.1" <[email protected]>
Reviewed-by: Kenneth Graunke <[email protected]>
|
|
|
|
|
|
|
| |
No need for all that switching when we can just assign a nice little
variable with the number of layers.
Reviewed-by: Kenneth Graunke <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
gen4 have commands which start with KernelStartPointer, which is a
struct, so if we initialize it struct = { 0 }, we get warnings on some
compilers:
"GCC (pre 4.9?) can throw a Wmissing-braces on[1] while clang
-Wmissing-field-initializers [2]." - Emil
[1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53119
[2] https://bugs.llvm.org/show_bug.cgi?id=21689
This change works around that and will silence such warnings. It is both
a GCC and a clang extension.
v2:
- Use {} instead of memset macro (Matt)
Signed-off-by: Rafael Antognolli <[email protected]>
Cc: Jason Ekstrand <[email protected]>
Cc: Matt Turner <[email protected]>
Cc: Emil Velikov <[email protected]>
Reviewed-by: Francisco Jerez <[email protected]>
|
|
|
|
|
|
|
|
|
| |
The extension should be in the list as returned by getExtensions().
Seems to have gone unnoticed since close to nobody wants to change the
vblank mode for the software driver.
Signed-off-by: Emil Velikov <[email protected]>
Reviewed-by: Alex Deucher <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The set of formats which supports CCS_E is actually fairly small on
gen9. However, everything that supports fast-clears on gen8 also
supports fast-clears on gen9+. The one very annoying exception is
that blending is broken for non-0/1 clear colors with sRGB formats.
In order to solve that problem, we do a resolve to get rid of the
clear color. Another option would be to just not fast-clear with
non-0/1 clear colors however non-0/1 + blending + sRGB is uncommon
enough that this shouldn't be a significant performance problem.
This appears to help gl_manhattan31_off by about 2%.
Reviewed-by: Topi Pohjolainen <[email protected]>
|