| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
| |
Add a 'static' pipe-loader build, which will be used with follow-up
commits.
Signed-off-by: Emil Velikov <[email protected]>
Reviewed-by: Chih-Wei Huang <[email protected]>
Acked-by: Rob Clark <[email protected]>
|
|
|
|
|
|
|
|
| |
Add a 'static' pipe-loader build, which will be used with follow-up
commits.
Signed-off-by: Emil Velikov <[email protected]>
Acked-by: Rob Clark <[email protected]>
|
|
|
|
|
|
|
|
| |
We cannot use this C99 feature here quite yet, as the code needs to be
build with MSVC prior to 2013.
Signed-off-by: Emil Velikov <[email protected]>
Acked-by: Rob Clark <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Unlike the inline ones, here we'd want to have an extern definition of
the functions. This is required as with follow-up commits, we'll
gradually start using the static pipe-loader, with the latter needing
the symbols.
These are direct copy from the inline version.
v2:
- rebase on top of virgl support
- add "driver missing" printfs (Nicolai)
Signed-off-by: Emil Velikov <[email protected]>
Acked-by: Rob Clark <[email protected]>
|
|
|
|
|
|
|
|
|
|
| |
Rather than having all targets include the file, with only some defining
the relevant guard macro, just move things where they are used.
v2: rebase on top of virgl support.
Signed-off-by: Emil Velikov <[email protected]>
Acked-by: Rob Clark <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
As of last few commits we have a static and dynamic pipe-loader. Either
of which will be used with (almost) all targets..
We can look into allowing the user to select which way the targets are
built, be that 'static for all' or 'per target' in follow up commits.
After which we can look into building only the static or dynamic
version, although building both shouldn't cause any issues.
Hack/workaround alert:
Control the standalone pipe-drivers via HAVE_CLOVER. Will need to be
fixed as the targets are converted/configure knobs are in.
Signed-off-by: Emil Velikov <[email protected]>
Acked-by: Rob Clark <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Analogous to previous commit with a small catch.
As the sw inline helpers are mere wrappers, and the screen <> winsys
split is more prominent (with the latter not being part of the final
pipe-driver), things will just work.
v2: rebase on top of earlier 'consolitate teardown' changes
Signed-off-by: Emil Velikov <[email protected]>
Acked-by: Rob Clark <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Add a list of driver descriptors and select one from the list, during
probe time.
As we'll need to have all the driver pipe_foo_screen_create() functions
provided externally (i.e. from another static lib) we need a separate
(non-inline) drm_helper, which contains the function declarations.
v2: rebase on top of virgl support.
Signed-off-by: Emil Velikov <[email protected]>
Acked-by: Rob Clark <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
| |
It is to be used in contrast of the dynamic one. The state-tracker does
not need to know if the pipe-driver is built into the final blob or
a separate object. This will allow us to move the logic to the final
step (in target) where the appropriate pipe-loader will be chosen.
Cc: Tom Stellard <[email protected]>
Cc: Francisco Jerez <[email protected]>
Signed-off-by: Emil Velikov <[email protected]>
Acked-by: Rob Clark <[email protected]>
|
|
|
|
|
|
|
|
|
| |
With the next commits we'll introduce a 'static' version, which will
essentially load the statically linked-in pipe-drivers, rather than the
standalone pipe-$foo.so ones.
Signed-off-by: Emil Velikov <[email protected]>
Acked-by: Rob Clark <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
| |
Rather than giving false hopes that things might work, just check at
probe time. This allows us to remove the duplication and consolidate
the code wrt the upcomming static pipe-loader.
Cc: Tom Stellard <[email protected]>
Cc: Francisco Jerez <[email protected]>
Signed-off-by: Emil Velikov <[email protected]>
Acked-by: Rob Clark <[email protected]>
|
|
|
|
|
|
|
|
|
| |
Already defined as such in struct pipe_loader_device::ops.
Cc: Tom Stellard <[email protected]>
Cc: Francisco Jerez <[email protected]>
Signed-off-by: Emil Velikov <[email protected]>
Acked-by: Rob Clark <[email protected]>
|
|
|
|
|
|
|
|
| |
i.e. plug some (hard to hit) memory leaks.
v2: fix rebase fallout - really teardown the winsys (Brian)
Signed-off-by: Emil Velikov <[email protected]>
Acked-by: Rob Clark <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
| |
Move the winsys into the pipe-target, similar to the hardware
pipe-driver.
v2:
- move int declaration outside of loop (Brian)
- fold the teardown into a goto + separate function.
Signed-off-by: Emil Velikov <[email protected]>
Acked-by: Rob Clark <[email protected]>
|
|
|
|
|
| |
Signed-off-by: Emil Velikov <[email protected]>
Acked-by: Rob Clark <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
| |
Due to the nature of the other sw winsys' we cannot use them during the
generic probe stage. As such there is little point in keeping the
abstraction layer.
Cc: Tom Stellard <[email protected]>
Cc: Francisco Jerez <[email protected]>
Signed-off-by: Emil Velikov <[email protected]>
Acked-by: Rob Clark <[email protected]>
|
|
|
|
|
|
|
|
|
| |
Allows us to fold the duplication in pipe_loader_sw_probe_*().
Cc: Tom Stellard <[email protected]>
Cc: Francisco Jerez <[email protected]>
Signed-off-by: Emil Velikov <[email protected]>
Acked-by: Rob Clark <[email protected]>
|
|
|
|
|
|
|
|
| |
The tests don't (and shouldn't) need to have anything driver and/or
winsys specific.
Signed-off-by: Emil Velikov <[email protected]>
Acked-by: Rob Clark <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Currently the location is determined at configure/build time and
consistently copied across gallium. Just remove the extra argument, and
use PIPE_SEARCH_DIR where appropriate.
This will allow us to remove the duplication in the *configuration and
*screen_create APIs by moving util_dl_get_proc_address() and friends to
probe time.
v2: rebase on top of vl_winsys_drm.c addition
Signed-off-by: Emil Velikov <[email protected]>
Acked-by: Rob Clark <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Since the up-streaming of nine, the static target was used by default.
The dynamic pipe-drivers being available only via manual tweak of
configure.ac.
As we'll be removing the library_path argument from the pipe-loader with
follow-up commits, we can remove D3D9_DRIVERS_PATH/D3D9_DRIVERS_DIR.
Everyone doing local hacking on nine, or wishing to have a env override
can bring them back within the pipe-loader.
Cc: Axel Davy <[email protected]>
Signed-off-by: Emil Velikov <[email protected]>
Acked-by: Rob Clark <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
| |
... in favour of HAVE_LIBDRM. After all we solely want to build the code
when the latter is available.
In the not too distant future we will remove the libudev/sysfs
dependency and simplify configure.ac even further.
Signed-off-by: Emil Velikov <[email protected]>
Acked-by: Rob Clark <[email protected]>
|
|
|
|
|
|
|
|
| |
Will be used as a counterpart for target-helpers'
kms_swrast_create_screen().
Signed-off-by: Emil Velikov <[email protected]>
Acked-by: Rob Clark <[email protected]>
|
|
|
|
|
|
|
| |
Using HAVE_DRI2 to manage it seems counter-intuitive.
Signed-off-by: Emil Velikov <[email protected]>
Acked-by: Rob Clark <[email protected]>
|
|
|
|
|
|
| |
Cc: Axel Davy <[email protected]>
Signed-off-by: Emil Velikov <[email protected]>
Acked-by: Rob Clark <[email protected]>
|
|
|
|
|
|
|
|
| |
As of last commit we no longer need the defines in order to have the
function prototypes.
Signed-off-by: Emil Velikov <[email protected]>
Acked-by: Rob Clark <[email protected]>
|
|
|
|
|
|
|
|
|
|
| |
They serve little to no purpose, as we don't need any additional
dependencies (headers and/or symbols). On the other hand dropping them
will allow us to use GALLIUM_PIPE_LOADER_DEFINES in only one single
place - the pipe-loader.
Signed-off-by: Emil Velikov <[email protected]>
Acked-by: Rob Clark <[email protected]>
|
|
|
|
|
|
|
|
|
| |
Currently every target makes sure that the screen is non-null prior to
using the debug (trace including) wrappers. If that no longer holds true
we want to know and fix this ASAP rather than silently bailing out.
Signed-off-by: Emil Velikov <[email protected]>
Acked-by: Rob Clark <[email protected]>
|
|
|
|
|
|
|
| |
Same as commit 84d087aea but for a4xx. The RE'd enums had the same issue
too.
Signed-off-by: Ilia Mirkin <[email protected]>
|
|
|
|
|
|
|
|
|
| |
a4xx hardware has real support for RGTC so there's no need to fake it
like we do on a3xx. Undo the hacks, and keep track of an "internal
format" of a resource, which on a3xx will be different, triggering the
transfer-time conversions to take place.
Signed-off-by: Ilia Mirkin <[email protected]>
|
|
|
|
| |
Signed-off-by: Ilia Mirkin <[email protected]>
|
|
|
|
| |
Signed-off-by: Ilia Mirkin <[email protected]>
|
|
|
|
| |
Signed-off-by: Ilia Mirkin <[email protected]>
|
|
|
|
|
|
|
|
|
| |
Looks like a4xx hw does this in a more standard way and we don't need to
hack around it like we do on a3xx. Fixes GL_ALPHA formats in
fbo-blending-formats, fbo-colormask-formats, and fbo-alphatest-formats.
Signed-off-by: Ilia Mirkin <[email protected]>
Cc: [email protected]
|
|
|
|
|
|
|
|
|
| |
This fixes CubeArrayShadow tests (where the shadow comes in via a second
arg to the TEX2 instruction).
Signed-off-by: Ilia Mirkin <[email protected]>
Reviewed-by: Rob Clark <[email protected]>
Cc: [email protected]
|
|
|
|
|
|
|
| |
Instead of playing the guessing game as to which texture format reads
from which border color encoding type, just write both of them always.
Signed-off-by: Ilia Mirkin <[email protected]>
|
|
|
|
|
|
|
| |
There are not native RGBX render formats, so we must manually force
dst_alpha to be one, same as for a3xx.
Signed-off-by: Ilia Mirkin <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The point of prepare_buffer is to ensure that the query buffer contains valid
initial data for conditional rendering: as long as the buffer is initialized
correctly, the GPU is able to tell whether query results have been written
already (and wait or fall back to unconditional rendering if desired).
This means prepare_buffer needs to be called again when a buffer is reused.
Conversely, for queries that cannot be used for conditional rendering
(notably pipeline statistics), we can re-use buffers immediately, and they
do not need to be initialized.
Reviewed-by: Marek Olšák <[email protected]>
Tested-by: Andy Furniss <[email protected]>
|
|
|
|
|
|
|
|
|
|
| |
Since begin_query is not called for this query type, we need to reset the
query buffer state in end_query instead.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=93015
Reviewed-by: Marek Olšák <[email protected]>
Tested-by: Andy Furniss <[email protected]>
Tested-by: Mathias Tillman <[email protected]>
|
|
|
|
|
|
|
|
| |
To graph the number of bytes uploaded to GPU per frame (vertex buffer data,
constant buffer data, texture data, etc).
Reviewed-by: José Fonseca <[email protected]>
Reviewed-by: Charmaine Lee <[email protected]>
|
|
|
|
|
|
|
| |
Make sure y and z values of buffers are as expected.
Reviewed-by: José Fonseca <[email protected]>
Reviewed-by: Charmaine Lee <[email protected]>
|
|
|
|
|
|
|
| |
This turns on GL_AMD_performance_monitor.
Signed-off-by: Samuel Pitoiset <[email protected]>
Acked-by: Ilia Mirkin <[email protected]>
|
|
|
|
|
|
|
|
| |
Only one encoding pipe available for Stoney
Signed-off-by: Leo Liu <[email protected]>
Reviewed-by: Alex Deucher <[email protected]>
Reviewed-by: Christian König <[email protected]>
|
|
|
|
|
|
|
|
| |
Add new interface to create and encode
Signed-off-by: Leo Liu <[email protected]>
Reviewed-by: Alex Deucher <[email protected]>
Reviewed-by: Christian König <[email protected]>
|
|
|
|
|
|
|
| |
The queries_suspended_for_flush flag is redundant because suspended queries
are not removed from their respective linked list.
Reviewed-by: Marek Olšák <[email protected]>
|
|
|
|
|
|
|
| |
v2 + v3: be more defensive about allocations
Reviewed-by: Samuel Pitoiset <[email protected]>
Tested-by: Samuel Pitoiset <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Some drivers (in particular radeon[si], but also freedreno judging from
a quick grep) may want to expose performance counters that cannot be
individually enabled or disabled.
Allow such drivers to mark driver-specific queries as requiring a new
type of batch query object that is used to start and stop a list of queries
simultaneously.
v3: adjust recently added nv50 queries
v2: documentation for create_batch_query
Reviewed-by: Samuel Pitoiset <[email protected]>
Tested-by: Samuel Pitoiset <[email protected]>
|
|
|
|
|
| |
Reviewed-by: Samuel Pitoiset <[email protected]>
Tested-by: Samuel Pitoiset <[email protected]>
|
|
|
|
|
| |
Reviewed-by: Samuel Pitoiset <[email protected]>
Tested-by: Samuel Pitoiset <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This was only used to implement an unnecessarily restrictive interpretation
of the spec of AMD_performance_monitor. The spec says
A performance monitor consists of a number of hardware and software
counters that can be sampled by the GPU and reported back to the
application.
I guess one could take this as a requirement that counters _must_ be sampled
by the GPU, but then why are they called _software_ counters? Besides,
there's not much reason _not_ to expose all counters that are available,
and this simplifies the code.
v3: add a missing change in the nouveau driver (thanks Samuel Pitoiset)
Reviewed-by: Samuel Pitoiset <[email protected]>
Tested-by: Samuel Pitoiset <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
texel fetches don't use any samplers. Previously we just set the same
number for both texture and sampler unit (as per "ordinary" gl style
sampling where the numbers are always the same) however this would trigger
some assertions checking that the sampler index isn't over PIPE_MAX_SAMPLERS
limit elsewhere with d3d10, so just set to 0.
(Fixing the assertion instead isn't really an option, the sampler isn't
really used but might still pass an out-of-bound pointer around and even
copy some things from it.)
Reviewed-by: Jose Fonseca <[email protected]>
|