| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Drop $(srcdir)/ prefix analogous to before the file (and rule) movement
and move it outside of the NEED_RADEON_LLVM conditional.
Otherwise the build may fail as below.
make[3]: *** No rule to make target 'common/sid_tables.h', needed by 'distdir'. Stop.
Fixes: b838f642371 "ac/debug: Move sid_tables.h generation to common
code."
Signed-off-by: Emil Velikov <[email protected]>
|
|
|
|
|
| |
Cc: "12.0 13.0" <[email protected]>
Signed-off-by: Emil Velikov <[email protected]>
|
|
|
|
| |
Signed-off-by: Emil Velikov <[email protected]>
|
|
|
|
|
|
|
|
|
|
| |
Changes from V1 -> V2:
- updated Copyright
- added $(top_srcdir)/src/gallium/winsys to include path (suggested by Emil)
- adapted driver to new renderonly API
Signed-off-by: Christian Gmeiner <[email protected]>
Acked-by: Emil Velikov <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This driver supports a wide range of Vivante IP cores like GC880,
GC1000, GC2000 and GC3000.
Changes from V1 -> V2:
- added missing files to actually integrate the driver into build system.
- adapted driver to new renderonly API
Signed-off-by: Christian Gmeiner <[email protected]>
Signed-off-by: Lucas Stach <[email protected]>
Signed-off-by: Philipp Zabel <[email protected]>
Signed-off-by: Rob Herring <[email protected]>
Signed-off-by: Russell King <[email protected]>
Signed-off-by: Wladimir J. van der Laan <[email protected]>
Acked-by: Emil Velikov <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This a very lightweight library to add basic support for renderonly
GPUs. A kms gallium driver must specify how a renderonly_scanout
objects gets created. Also it must provide file handles to the used
kms device and the used gpu device.
This could look like:
struct renderonly ro = {
.create_for_resource = renderonly_create_gpu_import_for_resource,
.kms_fd = fd,
.gpu_fd = open("/dev/dri/renderD128", O_RDWR | O_CLOEXEC)
};
The renderonly_scanout object exits for two reasons:
- Do any special treatment for a scanout resource like importing the
GPU resource into the scanout hw.
- Make it easier for a gallium driver to detect if anything special
needs to be done in flush_resource(..) like a resolve to linear.
A GPU gallium driver which gets used as renderonly GPU needs to be
aware of the renderonly library.
This library will likely break android support and hopefully will get
replaced with a better solution based on gbm2.
Changes from V1 -> V2:
- reworked the lifecycle of renderonly object (suggested by Nicolai Hähnle)
- killed the midlayer (suggested by Thierry Reding)
- made the API more explicit regarding gpu and kms fd's
- added some docs
Signed-off-by: Christian Gmeiner <[email protected]>
Acked-by: Emil Velikov <[email protected]>
Tested-by: Alexandre Courbot <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Once again, SPIR-V is insane... It allows you to place "patch"
decorations on structure members. Presumably, this is so that you can
do something such as
out struct S {
layout(location = 0) patch vec4 thing1;
layout(location = 0) vec4 thing2;
} str;
And have your I/O "nicely" organized. While this is a bit silly, it's
allowed and well-defined so whatever. Where it really gets interesting
is when you have an array of struct. SPIR-V says nothing about not
allowing you to have those qualifiers on the members of a struct that's
inside an array and GLSLang does this. Specifically, if you have
layout(location = 0) out patch struct S {
vec4 thing1;
vec4 thing2;
} str[2];
then GLSLang will place the "patch" decorations on the struct members.
This is ridiculous there is no way that having some of them be patch and
some not would be well-defined given that patch and non-patch outputs
are in effectively different storage classes. This commit moves around
the way we handle the "patch" decoration so that we can detect even the
crazy cases and handle them.
Fixes: dEQP-VK.tessellation.user_defined_io.per_patch_block_array.*
Reviewed-by: Kenneth Graunke <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch implements vk_icdNegotiateLoaderICDInterfaceVersion(), which
brings us to loader interface v3.
v2:
- Drop the pragmas. [emil]
- Advertise v3 instead of v2. Anvil supported more than I
thought. [jason]
- s/Surface/SurfaceKHR/ in comments. [emil]
Reviewed-by: Emil Velikov <[email protected]>
Cc: [email protected]
Cc: Jason Ekstrand <[email protected]>
|
|
|
|
|
|
|
|
| |
Import from commit f2aeefec on branch 'master'
of https://github.com/KhronosGroup/Vulkan-LoaderAndValidationLayers.
Reviewed-by: Emil Velikov <[email protected]>
Cc: [email protected]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We can't import the latest vk_icd.h because the new header breaks the
Mesa build. This patch defines new casting macros,
ICD_DEFINE_NONDISP_HANDLE_CASTS() and ICD_FROM_HANDLE(), which can
handle both the old and new vk_icd.h, and will prevent the build from
breaking when we update the header.
In the old vk_icd.h, types were defined as:
typedef struct _VkIcdFoo {
...
} VkIcdFoo;
Commit 6ebba1f6 in the Vulkan loader changed the above to
typedef {
...
} VkIcdFoo;
because the old definitions violated the C and C++ specs. According to
the specs, identifiers that begins with an underscore followed by an
uppercase letter are reserved. (It's pedantic, I know), See the Github
issue referenced below.
References: https://github.com/KhronosGroup/Vulkan-LoaderAndValidationLayers/issues/7
References: https://github.com/KhronosGroup/Vulkan-LoaderAndValidationLayers/commit/6ebba1f630015af7a78767a15c1e74ba9b23601c
Reviewed-by: Emil Velikov <[email protected]>
Cc: [email protected]
|
|
|
|
|
|
|
| |
Defer delete on regular resources. This ensures that any work being done
on the resource is completed before freeing up the resource's memory.
Reviewed-by: Bruce Cherniak <[email protected]>
|
|
|
|
|
|
| |
This fixes a defect detected by Coverity Scan.
Reviewed-by: Iago Toral Quiroga <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
| |
Although, arb_shader_image_load_store-atomicity will most likely
hang your box, I think it's now quite reasonable to enable GL 4.3
on Maxwell/Pascal GPUs. I suspect that test to be wrong because
it doesn't even work on the NVIDIA blob.
I have tested a bunch of benchmarks (UE4 demos) and real games
like Shadow of Mordor and they all work fine.
Signed-off-by: Samuel Pitoiset <[email protected]>
|
|
|
|
|
| |
Signed-off-by: Samuel Pitoiset <[email protected]>
Reviewed-by: Pierre Moreau <[email protected]>
|
|
|
|
|
|
| |
Signed-off-by: Samuel Pitoiset <[email protected]>
Reviewed-by: Pierre Moreau <[email protected]>
Acked-by: Ilia Mirkin <[email protected]>
|
|
|
|
|
|
|
|
|
|
| |
Yes, IMUL/IMAD require dependency barriers and we should
definitely replace these instructions by XMAD but the
different flags need to be figured out. Note that XMAD only
supports 16-bits integers.
Signed-off-by: Samuel Pitoiset <[email protected]>
Reviewed-by: Pierre Moreau <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This makes use of scheduling control codes which are very useful
for improving the instruction pipelining.
This patch will increase performance on Maxwell GPUs by, at least,
x1.5 up to x3.5 for some benchmarks.
Although this has been fairly well tested, I would not be suprised
if someone hit a corner case somewhere. That way, the scheduler
is enabled by default but it can be deactivated by using
NV50_PROG_SCHED=0.
Thanks to Scott Gray for the reverse engineering work available from
https://github.com/NervanaSystems/maxas/wiki/Control-Codes.
Signed-off-by: Samuel Pitoiset <[email protected]>
Acked-by: Pierre Moreau <[email protected]>
Tested-by: Alexandre Courbot <[email protected]>
Tested-by: Jan Vesely <[email protected]>
|
|
|
|
|
|
|
|
|
|
| |
It's actually useless to insert those texture barriers post RA
because the current control code (ie. st 0x0) will wait for all
dependencies before issuing a new instruction.
Signed-off-by: Samuel Pitoiset <[email protected]>
Reviewed-by: Ilia Mirkin <[email protected]>
Reviewed-by: Pierre Moreau <[email protected]>
|
|
|
|
|
|
|
|
|
| |
GL_ARB_vertex_attrib_64bit was the last piece missing.
v2: update docs (Jordan)
Signed-off-by: Juan A. Suarez Romero <[email protected]>
Reviewed-by: Jordan Justen <[email protected]>
|
|
|
|
|
|
|
|
| |
v2: update docs (Jordan)
Signed-off-by: Samuel Iglesias Gonsálvez <[email protected]>
Signed-off-by: Juan A. Suarez Romero <[email protected]>
Reviewed-by: Jordan Justen <[email protected]>
|
|
|
|
|
|
|
|
|
| |
ARB_vertex_attrib_64bit for HSW+
Signed-off-by: Samuel Iglesias Gonsálvez <[email protected]>
Signed-off-by: Juan A. Suarez Romero <[email protected]>
Reviewed-by: Jordan Justen <[email protected]>
|
|
|
|
|
|
|
|
| |
v2: update docs (Jordan)
Signed-off-by: Alejandro Piñeiro <[email protected]>
Signed-off-by: Juan A. Suarez Romero <[email protected]>
Reviewed-by: Jordan Justen <[email protected]>
|
|
|
|
|
|
|
| |
Those not supporting 64 bit input vertex attributes will have the
dual_slot value as false.
Reviewed-by: Jordan Justen <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
For dvec3 and dvec4 types, a single GRF do not have enough space to
allocate two inputs from two different vertices (SIMD4x2).
So the GRF only contains first two components for the two vertices, and
the next GRF has the remaining components.
We want to put all the components for the same vertex in the same
register. Thus, we do a shuffle to reorder the data.
Reviewed-by: Jordan Justen <[email protected]>
|
|
|
|
|
|
|
|
|
|
| |
Doubles needs more that one slot per attribute. So when filling the
attribute_map we check if it is a double in order to allocate one
extra register.
Signed-off-by: Alejandro Piñeiro <[email protected]>
Signed-off-by: Juan A. Suarez Romero <[email protected]>
Reviewed-by: Jordan Justen <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Doubles need extra space, so we would need to do a remapping for vec4
too in order to take that into account. We reuse the already
existing remap_vs_attrs, but passing is_scalar, so they could
remap accordingly.
v2: code-format remap_vs_attrs_params initialization (Matt)
Signed-off-by: Alejandro Piñeiro <[email protected]>
Signed-off-by: Juan A. Suarez Romero <[email protected]>
Reviewed-by: Jordan Justen <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
As part of the payload setup, setup_attributes is called with the first
GRF that can be used for the attributes (first ones are used for
uniforms for example) and returns the first GRF that is not part of the
payload. Before this patch, it adds directly the number of attributes.
But as with 64-bit attributes can consume more than one slot, that is
not valid anymore. This patch change the addition to use the number of
slots consumed.
gen >= 8 would not be affected, as they use the scalar mode. For that
case, the vs configuration is done at fs_visitor::assign_vs_urb_setup.
v2: add explanation in commit log (Jordan)
Reviewed-by: Jordan Justen <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
| |
gen < 8 doesn't support *64*PASSTHRU formats when emitting
vertices. So in order to provide the equivalent functionality, we need
to downsize the format to equivalent *32*FLOAT, and in some cases
(R64G64B64 and R64G64B64A64) submit two 3DSTATE_VERTEX_ELEMENTS for
each vertex element.
Signed-off-by: Alejandro Piñeiro <[email protected]>
Signed-off-by: Juan A. Suarez Romero <[email protected]>
Reviewed-by: Jordan Justen <[email protected]>
|
|
|
|
|
|
|
|
| |
Although gen7 doesn't include surface types as a valid conversion format,
we return it, as it reflects what we want to achieve, even if we need
to workaround it on gen < 8.
Reviewed-by: Jordan Justen <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
From OpenGL 3.1 spec, section 4.3.1 "Reading Pixels", page 190 (203 PDF)
"When READ FRAMEBUFFER BINDING is zero, i.e. the default
framebuffer, src must be one of the values listed in table 4.4,
including NONE . FRONT_AND_BACK , FRONT , and LEFT refer to the
front left buffer."
There is an equivalent text on OpenGL 4.5 spec, section 18.2.1
"Selecting Buffers for Reading", page 502 (524 PDF), so the behaviour
is still the same.
Part of the fix for:
GL45-CTS.direct_state_access.framebuffers_draw_read_buffers_errors
Reviewed-by: Anuj Phogat <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Before 4.5, GL_BACK was not allowed as a value of bufs. Since 4.5 it
is allowed under some circumstances:
From the OpenGL 4.5 specification, Section 17.4.1 "Selecting Buffers
for Writing", page 493 (page 515 of the PDF):
"An INVALID_ENUM error is generated if any value in bufs is FRONT,
LEFT, RIGHT, or FRONT_AND_BACK . This restriction applies to both
the de- fault framebuffer and framebuffer objects, and exists
because these constants may themselves refer to multiple buffers, as
shown in table 17.4."
And on page 492 (page 514 of the PDF):
"If the default framebuffer is affected, then each of the constants
must be one of the values listed in table 17.6 or the special value
BACK . When BACK is used, n must be 1 and color values are written
into the left buffer for single-buffered contexts, or into the back
left buffer for double-buffered contexts."
This patch keeps the same behaviour if OpenGL version is < 4. We
assume that for 4.x this is the intended behaviour, so a fix, but for
3.x the intended behaviour is the already in place.
Part of the fix for:
GL45-CTS.direct_state_access.framebuffers_draw_read_buffers_errors
v2: remove forgot printf
v3: remove spaces before commas on spec quote, split line too
long (Anuj)
Reviewed-by: Anuj Phogat <[email protected]>
|
|
|
|
|
|
| |
The old setting didn't hurt, but this is cleaner.
Reviewed-by: Marek Olšák <[email protected]>
|
|
|
|
|
|
| |
v2: use more generic description (Jordan)
Reviewed-by: Jordan Justen <[email protected]>
|
|
|
|
| |
Reviewed-by: Samuel Iglesias Gonsálvez <[email protected]>
|
|
|
|
|
|
|
|
|
|
| |
Predication needs cmd parser only on gen7. For newer platforms, it
should be available without it.
v2 (Ken): rebase on recent changes.
Signed-off-by: Rafael Antognolli <[email protected]>
Signed-off-by: Kenneth Graunke <[email protected]>
|
|
|
|
|
|
|
|
| |
Currently its dependant on the user calling and checking the result
of list_empty() before using the result of list_is_singular().
Cc: "13.0" <[email protected]>
Reviewed-by: Jason Ekstrand <[email protected]>
|
|
|
|
|
|
|
|
|
| |
We currently don't perform clears or resolves on multiple array layers
with HiZ.
Cc: [email protected]
Signed-off-by: Nanley Chery <[email protected]>
Reviewed-by: Jason Ekstrand <[email protected]>
|
|
|
|
|
|
|
|
|
|
| |
Match the comment above the field by using units of pixels and not HiZ
blocks.
Cc: [email protected]
Suggested-by: Jason Ekstrand <[email protected]>
Signed-off-by: Nanley Chery <[email protected]>
Reviewed-by: Jason Ekstrand <[email protected]>
|
|
|
|
|
|
|
|
|
|
| |
Enable multiple layers of the depth/stencil buffers to be accessible.
Fixes the crucible test, func.depthstencil.arrayed_clear.
Cc: [email protected]
Signed-off-by: Nanley Chery <[email protected]>
Reviewed-by: Jason Ekstrand <[email protected]>
|
|
|
|
|
|
|
|
|
|
| |
Without this check, the kernel::bind() method would fail with a
std::out_of_range exception, letting an exception escape from the
library into the client, rather than returning the corresponding error
code CL_INVALID_PROGRAM_EXECUTABLE.
Signed-off-by: Pierre Moreau <[email protected]>
Reviewed-by: Francisco Jerez <[email protected]>
|
|
|
|
|
|
| |
We don't want to do anything for the other cases.
Signed-off-by: Kenneth Graunke <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Otherwise we will end up with an extra instruction to compare the
result of the inot.
On BDW:
total instructions in shared programs: 13060620 -> 13060481 (-0.00%)
instructions in affected programs: 103379 -> 103240 (-0.13%)
helped: 127
HURT: 0
total cycles in shared programs: 256590950 -> 256587408 (-0.00%)
cycles in affected programs: 11324730 -> 11321188 (-0.03%)
helped: 114
HURT: 21
Reviewed-by: Jason Ekstrand <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We turn these from bcsel into inot/b2f combos in order for other
optimisation passes to get further. Once we have finished turn
the ones that remain and are used in more than a single expression
back into a bcsel.
On BDW:
total instructions in shared programs: 13060965 -> 13060297 (-0.01%)
instructions in affected programs: 835701 -> 835033 (-0.08%)
helped: 670
HURT: 2
total cycles in shared programs: 256599536 -> 256598006 (-0.00%)
cycles in affected programs: 114655488 -> 114653958 (-0.00%)
helped: 419
HURT: 240
LOST: 0
GAINED: 1
The 2 HURT is because inserting bcsel creates the only use of
const 1.0 in two shaders from tri-of-friendship-and-madness.
Reviewed-by: Jason Ekstrand <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
On BDW:
total instructions in shared programs: 13061890 -> 13061877 (-0.00%)
instructions in affected programs: 2441 -> 2428 (-0.53%)
helped: 13
HURT: 0
total cycles in shared programs: 256612254 -> 256611784 (-0.00%)
cycles in affected programs: 16418 -> 15948 (-2.86%)
helped: 10
HURT: 2
V2: don't use ffma directly
Reviewed-by: Jason Ekstrand <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
While the below stats are encouraging this pass will also become
very usefull for avoiding regression once
brw_do_channel_expressions() and brw_do_vector_splitting() are
disabled.
On Broadwell:
total instructions in shared programs: 13078787 -> 13060898 (-0.14%)
instructions in affected programs: 1809827 -> 1791938 (-0.99%)
helped: 4527
HURT: 157
total cycles in shared programs: 256562762 -> 256590424 (0.01%)
cycles in affected programs: 159749392 -> 159777054 (0.02%)
helped: 5583
HURT: 2289
total spills in shared programs: 14929 -> 14923 (-0.04%)
spills in affected programs: 62 -> 56 (-9.68%)
helped: 1
HURT: 0
total fills in shared programs: 20144 -> 20141 (-0.01%)
fills in affected programs: 253 -> 250 (-1.19%)
helped: 1
HURT: 3
LOST: 0
GAINED: 2
Signed-off-by: Kenneth Graunke <[email protected]>
Reviewed-by: Timothy Arceri <[email protected]>
Reviewed-by: Jason Ekstrand <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
I'm going to add a boolean scheduling pass that I want run late, but
after copy propagation and dead code elimination. Yet, I don't want
to have to think about registers. So, move the register conversion
a little later.
No impact on shader-db. Suggested by Jason Ekstrand.
Signed-off-by: Kenneth Graunke <[email protected]>
Reviewed-by: Jason Ekstrand <[email protected]>
Reviewed-by: Timothy Arceri <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This tries to move comparisons (a common source of boolean values)
closer to their first use. For GPUs which use condition codes,
this can eliminate a lot of temporary booleans and comparisons
which reload the condition code register based on a boolean.
V2: (Timothy Arceri)
- fix move comparision for phis so we dont end up with:
vec1 32 ssa_227 = phi block_34: ssa_1, block_38: ssa_240
vec1 32 ssa_235 = feq ssa_227, ssa_1
vec1 32 ssa_230 = phi block_34: ssa_221, block_38: ssa_235
- add nir_op_i2b/nir_op_f2b to the list of comparisons.
V3: (Timothy Arceri)
- tidy up suggested by Jason.
- add inot/fnot to move comparison list
V4: (Jason Ekstrand)
- clean up move_comparison_source
- get rid of the tuple
- rework phi handling
Signed-off-by: Kenneth Graunke <[email protected]>
Reviewed-by: Ian Romanick <[email protected]> [v1]
Reviewed-by: Jason Ekstrand <[email protected]>
|
|
|
|
| |
Reviewed-by: Jason Ekstrand <[email protected]>
|
| |
|
|
|
|
|
|
|
|
| |
This is more correct and should also be a tiny bit faster since we're
just comparing pointers instead of calling nir_src_equal.
Reviewed-by: Timothy Arceri <[email protected]>
Cc: "13.0" <[email protected]>
|