| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
| |
V2 (Timothy Arceri):
- fix copy and paste error with error message
V3 (Timothy Arceri):
- drop the Protected field for now as its unused
Signed-off-by: Andres Rodriguez <[email protected]>
Reviewed-by: Timothy Arceri <[email protected]>
Reviewed-by: Samuel Pitoiset <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Used by EXT_external_objects and EXT_external_objects_fd
V2 (Timothy Arceri):
- Throw GL_OUT_OF_MEMORY error if CreateMemoryObjectsEXT()
fails.
- C99 tidy ups
- remove void cast (Constantine Kharlamov)
V3 (Timothy Arceri):
- rename mo -> memObj
- check that the object is not NULL before initializing
- add missing "EXT" in function error message
V4 (Timothy Arceri):
- remove checks for (memory objecy id == 0) and catch in
_mesa_lookup_memory_object() instead.
Signed-off-by: Andres Rodriguez <[email protected]>
Reviewed-by: Samuel Pitoiset <[email protected]>
|
|
|
|
|
|
|
|
| |
Includes implementation stubs.
Signed-off-by: Andres Rodriguez <[email protected]>
Acked-by: Timothy Arceri <[email protected]>
Acked-by: Samuel Pitoiset <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The device version is the maximum CL version that the device supports.
device_version and device_clc_version are not necessarily the same for
devices that support CL 1.0, but have a 1.1 compiler and the necessary
extensions.
Eventually, this will be based on the features/extensions of the actual
device, but for now move it a bit closer to its eventual destination.
Signed-off-by: Aaron Watry <[email protected]>
Reviewed-by: Jan Vesey <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is a bug in the app, but I'd rather avoid hanging the GPU,
esp if someone is running in validation and it takes out their
development environment.
v2: get it right, reverse the polarity.
Reviewed-by: Bas Nieuwenhuizen <[email protected]>
Cc: <[email protected]>
Signed-off-by: Dave Airlie <[email protected]>
|
|
|
|
|
|
|
|
|
|
| |
Having two callbacks to manage a single int seems like an overkill.
Use a cached copy and update that when needed.
Signed-off-by: Emil Velikov <[email protected]>
---
Might want to look if the dimensions dance in .query_surface ...
speaking of which close to nobody implements that ...
|
|
|
|
|
|
|
|
|
| |
If we get a xfixes v1.x we'll error out, without freeing the
xfixes_query reply.
Cc: <[email protected]>
Signed-off-by: Emil Velikov <[email protected]>
Reviewed-by: Eric Engestrom <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Currently xmlconfig is conditionally used, only when --enable-dri is
available.
As the library has moved to src/util and has wider wisebase, this guard
is no longer correct. Strictly speaking - it wasn't since the
introduction of xmlconfig into st/nine a while ago.
Unconditionally enable xmlconfig and drop the linking. As said before
there's other users of the library, so depending on the configure
options we will get multiple definitions of said symbols.
NOTE: To avoid breaking other combinations, this commit adds the
xmlconfig link to the required places - throughout gallium and the DRI
loaders.
Cc: Aaron Watry <[email protected]>
Signed-off-by: Emil Velikov <[email protected]>
Reviewed-by: Nicolai Hähnle <[email protected]>
Tested-by: Dieter Nützel <[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.
|
|
|
|
|
|
|
|
|
|
|
|
| |
Use the .pc file, as provided by version prior 2.1.0 onward and dropping
the manual header/library check.
Version 2.1.0 was released back in Mar 2012 and all major distributions
use it.
Signed-off-by: Emil Velikov <[email protected]>
Reviewed-by: Nicolai Hähnle <[email protected]>
Reviewed-by: Eric Engestrom <[email protected]> (IRC)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Earlier commits moved the xmlconfig library to a wider userbase.
Thus having the check within --enable-dri is insufficient.
Upon closer look, nine needed it from it's early days - 948e6c52282
("nine: Add drirc options (v2)")
Fixes: 601093f95ddf ("xmlconfig: move into src/util")
Cc: Axel Davy <[email protected]>
Signed-off-by: Emil Velikov <[email protected]>
Reviewed-by: Nicolai Hähnle <[email protected]>
Reviewed-by: Eric Engestrom <[email protected]> (IRC)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Android build changes to avoid the following building error:
target C: libmesa_pipe_radeonsi <= external/mesa/src/gallium/drivers/radeonsi/si_pipe.c
...
In file included from external/mesa/src/gallium/drivers/radeonsi/si_pipe.c:38:
external/mesa/src/compiler/nir/nir.h:48:10: fatal error: 'nir_opcodes.h' file not found
^
1 error generated.
Fixes: da62a31c5b "radeonsi: add nir include paths"
Reviewed-by: Emil Velikov <[email protected]>
|
|
|
|
|
|
|
|
|
|
| |
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]>
|
|
|
|
|
|
|
|
| |
Missed updating this caller of pipe_loader_find_module.
Fixes: 0d7d60b7ea ("pipe-loader: pass only the driver_name to pipe_loader_find_module")
Tested-by: Dieter Nützel <[email protected]>
Reviewed-by: Marek Olšák <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
| |
The config passed into the screen should be independent from the state
tracker, because at least in the case of radeonsi, the screen structure
can be shared between different state trackers.
Incidentally, this also fixes crashes that were recently introduced.
Fixes: a35a9e7c ("gallium: add driconf options to pipe_screen_config")
Tested-by: Dieter Nützel <[email protected]>
Reviewed-by: Marek Olšák <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
| |
They were set only by the DRI state tracker, which is problematic
when radeonsi is used with different state trackers in the same
process.
Also, we don't need them anymore.
Tested-by: Dieter Nützel <[email protected]>
Reviewed-by: Marek Olšák <[email protected]>
|
|
|
|
|
|
|
|
| |
Also, access the options directly, allowing us to get rid of the
PIPE_SCREEN_xxx flags.
Tested-by: Dieter Nützel <[email protected]>
Reviewed-by: Marek Olšák <[email protected]>
|
|
|
|
| |
Reviewed-by: Emil Velikov <[email protected]>
|
|
|
|
| |
Reviewed-by: Emil Velikov <[email protected]>
|
|
|
|
|
|
|
|
|
| |
Commit 0ab04ba979b7 (anv: Use python to generate ICD json files) changed
the way ICD json files are created.
Remove the old .in files from extra dist, and add the python script.
Reviewed-by: Emil Velikov <[email protected]>
|
|
|
|
|
|
|
| |
This fixes the image descriptors for mipmapped tile swizzle
Fixes: 2b7e8556 (ac/surface: enable tile swizzle for mipmapped textures)
Signed-off-by: Dave Airlie <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
| |
When Marek enabled mipmapped swizzle, radv didn't
have the code in place to handle it. This fixes the
regression.
I'll look more into GFX9 once I have a vega card (soon).
Fixes: 2b7e8556 (ac/surface: enable tile swizzle for mipmapped textures)
Signed-off-by: Dave Airlie <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Fixes out-of-tree build failure:
.../src/gallium/targets/pipe-loader/pipe_radeonsi.c: In function ‘drm_configuration’:
.../src/gallium/targets/pipe-loader/pipe_radeonsi.c:38:33: fatal error: radeonsi/si_driinfo.h: No such file or directory
#include "radeonsi/si_driinfo.h"
^
compilation terminated.
Makefile:994: recipe for target 'pipe_radeonsi.lo' failed
make[4]: *** [pipe_radeonsi.lo] Error 1
Trivial.
Fixes: 0f8c5de8690e7c ("radeonsi: prepare for driver-specific driconf
options")
|
|
|
|
|
| |
Signed-off-by: Jan Vesely <[email protected]>
Reviewed-by: Francisco Jerez <[email protected]>
|
|
|
|
|
| |
Reviewed-by: Dave Airlie <[email protected]>
Reviewed-by: Nicolai Hähnle <[email protected]>
|
|
|
|
|
| |
Reviewed-by: Dave Airlie <[email protected]>
Reviewed-by: Nicolai Hähnle <[email protected]>
|
|
|
|
|
| |
Reviewed-by: Dave Airlie <[email protected]>
Reviewed-by: Nicolai Hähnle <[email protected]>
|
|
|
|
|
| |
Reviewed-by: Dave Airlie <[email protected]>
Reviewed-by: Nicolai Hähnle <[email protected]>
|
|
|
|
|
|
|
|
| |
Note that dcc_alignment = pipe_interleave_bytes * num_pipes * num_banks,
which is greater than the previous open-coded alignment.
Reviewed-by: Dave Airlie <[email protected]>
Reviewed-by: Nicolai Hähnle <[email protected]>
|
|
|
|
|
|
|
| |
Mipmapping with tile swizzle doesn't work.
Reviewed-by: Dave Airlie <[email protected]>
Reviewed-by: Nicolai Hähnle <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
| |
The tile swizzle computation was done after the whole miptree was computed,
but that was too late, because at that point AddrSurfInfoOut contained
information about the smallest miplevel, which is never 2D-tiled.
The correct way is to do the computation before the second level is computed.
Reviewed-by: Dave Airlie <[email protected]>
Reviewed-by: Nicolai Hähnle <[email protected]>
|
|
|
|
|
| |
Reviewed-by: Dave Airlie <[email protected]>
Reviewed-by: Nicolai Hähnle <[email protected]>
|
|
|
|
|
| |
Reviewed-by: Dave Airlie <[email protected]>
Reviewed-by: Nicolai Hähnle <[email protected]>
|
|
|
|
|
| |
Reviewed-by: Dave Airlie <[email protected]>
Reviewed-by: Nicolai Hähnle <[email protected]>
|
|
|
|
|
|
|
| |
Shareable textures won't use tile swizzle.
Reviewed-by: Dave Airlie <[email protected]>
Reviewed-by: Nicolai Hähnle <[email protected]>
|
|
|
|
|
|
|
| |
it's useless
Reviewed-by: Dave Airlie <[email protected]>
Reviewed-by: Nicolai Hähnle <[email protected]>
|
|
|
|
|
|
|
| |
Gfx9 will use it too.
Reviewed-by: Dave Airlie <[email protected]>
Reviewed-by: Nicolai Hähnle <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In Mesa we use the convention that if gl_renderbuffer::NumSamples
or gl_texture_image::NumSamples is zero, it's a non-MSAA surface.
Otherwise, it's an MSAA surface. But in gallium nr_samples=1 is a
non-MSAA surface.
Before, if the user called glRenderbufferStorageMultisample() or
glTexImage2DMultisample() with samples=1 we skipped the search for the
next higher number of supported samples and asked the gallium driver to
create a surface with nr_samples=1. So we got a non-MSAA surface.
This failed to meet the expection of the user making those calls.
This patch changes the sample count checks in st_AllocTextureStorage()
and st_renderbuffer_alloc_storage() to test for samples > 0 instead of > 1.
And we now start querying for MSAA support at samples=2 since gallium has
no concept of a 1x MSAA surface.
A specific example of this problem is the Piglit arb_framebuffer_srgb-blit
test. It calls glRenderbufferStorageMultisample() with samples=1 to
request an MSAA renderbuffer with the minimum supported number of MSAA
samples. Instead of creating a 4x or 8x, etc. MSAA surface, we wound up
creating a non-MSAA surface.
Finally, add a comment on the gl_renderbuffer::NumSamples field.
There is one piglit regression with the VMware driver:
ext_framebuffer_multisample-blit-mismatched-formats fails because
now we're actually creating 4x MSAA surfaces (the requested sample
count is 1) and we're hitting some sort of bug in the blitter code. That
will have to be fixed separately. Other drivers may find regressions
too now that MSAA surfaces are really being created.
v2: start quering for MSAA support with samples=2 instead of 1.
Reviewed-by: Roland Scheidegger <[email protected]>
Reviewed-by: Marek Olšák <[email protected]>
|