In prep for GFX9 refactor some of the eop event writing code
out.
This changes behaviour, but aligns with what radeonsi does,
it does double emits on CIK/VI, whereas previously it only
did this on CIK.
v2: bump the size checks.
Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
Signed-off-by: Dave Airlie <airlied@redhat.com>
This code was in a few places, consolidate into one.
Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Frequently, get_image_offset_sa is combined with get_intratile_offset_sa
so it makes sense to have a single helper to do both. If the caller
doesn't want the intratile offsets, it can simply pass NULL and ISL will
assert that they are 0.
Reviewed-by: Topi Pohjolainen <topi.pohjolainen@intel.com>
The only surface layout for which slice0 makes any sense is GEN4_2D.
Move all of the slice0 stuff into isl_calc_phys_total_extent_el_gen4_2d
and make the others trivially return the total size in surface elements.
As a side-effect, array_pitch_el_rows is now returned from these helpers
as well.
Reviewed-by: Topi Pohjolainen <topi.pohjolainen@intel.com>
We've already implicitly been using a physical total size in surface
elements. This just centralizes things a bit.
Reviewed-by: Topi Pohjolainen <topi.pohjolainen@intel.com>
This is a fairly common operation and it's nice to be able to just call
the one little function.
Reviewed-by: Topi Pohjolainen <topi.pohjolainen@intel.com>
Over 90% of the function only applies to ISL_DIM_LAYOUT_GEN4_2D anyway
so we can just handle the other two as special cases at the top. The
two "generic" cases below the switch only apply on gen9 and above and
only to 3D or CCS surfaces. This implies that they only apply to
surfaces with ISL_DIM_LAYOUT_GEN4_2D. Making them look generic is a
lie.
Reviewed-by: Topi Pohjolainen <topi.pohjolainen@intel.com>
We were only using it for validating that we don't use Ys/Yf on gen8 and
earlier. Removing it from isl_tiling_get_info lets us remove it from a
bunch of other things that had no business needing a hardware
generation.
Reviewed-by: Topi Pohjolainen <topi.pohjolainen@intel.com>
Sandy Bridge does not technically support mipmapped depth/stencil. In
order to work around this, we allocate what are effectively completely
separate images for each miplevel, ensure that they are page-aligned,
and manually offset to them. Prior to layered rendering, this was a
simple matter of setting a large enough halign/valign.
With the advent of layered rendering, however, things got more
complicated. Now, things weren't as simple as just handing a surface
off to the hardware. Any miplevel of a normally mipmapped surface can
be considered as just an array surface given the right qpitch. However,
the hardware gives us no capability to specify qpitch so this won't
work. Instead, the chosen solution was to use a new "all slices at each
LOD" layout which laid things out as a mipmap of arrays rather than an
array of mipmaps. This way you can easily offset to any of the
miplevels and each is a valid array.
Unfortunately, the "all slices at each lod" concept missed one
fundamental thing about SNB HiZ and stencil hardware: It doesn't just
always act as if you're always working with a non-mipmapped surface, it
acts as if you're always working on a non-mipmapped surface of the same
size as LOD0. In other words, even though it may only write the
upper-left corner of each array slice, the qpitch for the array is for a
surface the size of LOD0 of the depth surface. This mistake causes us
to under-allocate HiZ and stencil in some cases and also to accidentally
allow different miplevels to overlap. Sadly, piglit test coverage
didn't quite catch this until I started making changes to the resolve
code that caused additional HiZ resolves in certain tests.
This commit switches Sandy Bridge HiZ and stencil over to a new scheme
that lays out the non-zero miplevels horizontally below LOD0. This way
they can all have the same qpitch without interfering with each other.
Technically, the miplevels still overlap, but things are spaced out
enough that each page is only in the "written area" of one LOD.
Cc: "17.0 17.1" <mesa-stable@lists.freedesktop.org>
Reviewed-by: Topi Pohjolainen <topi.pohjolainen@intel.com>
We were linking src/glx with -Bsymbolic, but not the classic/gallium X11
libGL.so.
But it's always a good idea to build all libGL.so and all DRI drivers
with -Bsymbolic, otherwise they might resolve symbols from the 3rd party
application executable or shared libraries, which is _never_ what we
want.
In particular, this can happen when intercepting OpenGL calls with
apitrace, before
63194b2573
Cc: mesa-stable@lists.freedesktop.org
Reviewed-by: Brian Paul <brianp@vmware.com>
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
This function never occurs in the callchain of a GL function. It occurs
only in the callchain of eglCreate*Surface and the analogous paths for
GLX. Therefore, even if a thread does have a bound GL context,
emitting a GL error here is wrong. A misplaced GL error, when no GL
call is made, can confuse clients.
Cc: mesa-stable@lists.freedesktop.org
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
translate_tex_format() asserted that isl_format != 0. But 0 is a valid
format, ISL_FORMAT_R32G32B32A32_FLOAT.
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
It returns an isl_format, not GLuint BRW_FORMAT. I updated every
translate_tex_format() found by git-grep.
No change in behavior.
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
It returns an isl_format, not uint32_t BRW_FORMAT.
I updated every brw_isl_format_for_mesa_format() found by git-grep.
No change in behavior.
v2: Rebased atop Anuj's patch, which has some of the same fixes.
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net> (v1)
This patch makes non functional changes. Renaming is just to
make the code more readable.
V2: update the types to "enum isl_format"
Signed-off-by: Anuj Phogat <anuj.phogat@gmail.com>
Reviewed-by: Chad Versace <chadversary@chromium.org>
If the EGLImage's format is not a supported texture format according to
brw_surface_formats.c, then refuse to create the miptree. This follows
the precedent in glEGLImageRenderbufferStorage (implemented by
intel_image_target_renderbuffer_storage), which rejects the EGLImage's
format if is not renderable.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
If you had a group as the first element of a struct, i.e.
<struct name="3DSTATE_CONSTANT_BODY" length="10">
<group count="4" start="0" size="16">
<field name="ReadLength" start="0" end="15" type="uint"/>
</group>
...
</struct>
we would get a group_offset of 0, causing create_field() to think the
field wasn't in a group, and fail to offset forward for successive array
elements. So we'd mark all the array elements as offset 0.
Using ctx->group->elem_size is a better check for "are we in a group?".
Acked-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
If you have something like:
<group count="0" start="96" size="32">
<field name="Entry_0" start="0" end="15" type="GATHER_CONSTANT_ENTRY"/>
<field name="Entry_1" start="16" end="31" type="GATHER_CONSTANT_ENTRY"/>
</group>
We would reset ctx->group_count to 0 after processing the first field,
so the second would not have a group count.
This is largely untested, as the only groups with multiple fields are
packets we don't emit in Mesa. Found by inspection.
Acked-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Fixes for:
src/util/rand_xor.c:60:13: error: implicit declaration of function 'open' [-Werror=implicit-function-declaration]
int fd = open("/dev/urandom", O_RDONLY);
^~~~
src/util/rand_xor.c:60:34: error: 'O_RDONLY' undeclared (first use in this function)
int fd = open("/dev/urandom", O_RDONLY);
^~~~~~~~
Signed-off-by: Nicolas Dechesne <nicolas.dechesne@linaro.org>
Reviewed-by: Eric Engestrom <eric.engestrom@imgtec.com>
The cpu_fini() call pushes the buffer back into the GPU domain, which needs
to be done for all buffers, not just the ones with CPU written content. The
etnaviv kernel driver currently doesn't validate this, but may start to do
so at a later point in time. If there is a temporary resource the fini needs
to happen before the RS uses this one as the source for the upload.
Also remove an invalid comment about flushing CPU caches, cpu_fini takes
care of everything involved in this.
Fixes: c9e8b49b88 ("etnaviv: gallium driver for Vivante GPUs")
Cc: mesa-stable@lists.freedesktop.org
Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
Reviewed-by: Philipp Zabel <p.zabel@pengutronix.de>
Reviewed-By: Wladimir J. van der Laan <laanwj@gmail.com>
Bindless samplers/images are represented with 64-bit unsigned
integers and they can be assigned with explicit constructors.
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Reviewed-by: Timothy Arceri <tarceri@itsqueeze.com>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Memory/format layout qualifiers shouldn't be lost when arrays
of images are splitted by this pass.
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Reviewed-by: Timothy Arceri <tarceri@itsqueeze.com>
GL_ARB_bindless_texture allows images to be declared inside
structures, but when memory/format qualifiers are used, they
should be propagated when structures are splitted.
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Reviewed-by: Timothy Arceri <tarceri@itsqueeze.com>
We can initialize structs directly, avoid some temporaries, and cut out
about half of the skip component handling.
Reviewed-by: Rafael Antognolli <rafael.antognolli@intel.com>
We can just update the gl_transform_feedback_info fields at link time
to make the VUE header fields have the right location and component.
Then we don't need to handle them specially at draw time, which is
expensive.
Reviewed-by: Rafael Antognolli <rafael.antognolli@intel.com>
These were correct since they were used only in conversions to signed integers,
however this makes the implementation a bit more is more consistent and reduces
chances of propagating use of these macros to unsigned cases in the future, which
would not be correct.
Reviewed-by: Matt Turner <mattst88@gmail.com>
As we do for all other cases of float/double conversions to integers.
v2: use round() instead of IROUND() macros (Iago)
Reviewed-by: Matt Turner <mattst88@gmail.com>
v2:
- need unsigned rounding for double->uint64 conversion (Nicolai)
- use round() instead of IROUND() macros (Iago)
Reviewed-by: Matt Turner <mattst88@gmail.com>
Like we do for the 32-bit case.
v2:
- need unsigned rounding for float->uint64 conversion (Nicolai)
- use roundf() instead of IROUND() macros (Iago)
Reviewed-by: Matt Turner <mattst88@gmail.com>
Section 2.2.2 (Data Conversions For State Query Commands) of the
OpenGL 4.5 October 24th 2016 specification says:
"If a command returning unsigned integer data is called, such as
GetSamplerParameterIuiv, negative values are clamped to zero."
v2: uint to int conversion should clamp to INT_MAX (Nicolai)
v3 (Iago)
- Add conversions conversions from 64-bit integer paths
- Rebase on master
v4:
- need unsigned rounding for float/double->uint conversions (Nicolai)
- use round{f}() instead of IROUND() macros (Iago)
Fixes:
KHR-GL45.gpu_shader_fp64.state_query
Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com> (v2)
Reviewed-by: Matt Turner <mattst88@gmail.com>
Dave Airlie
Jason Ekstrand
Jason Ekstrand
Kenneth Graunke
Jose Fonseca
Chad Versace
Anuj Phogat
Eric Engestrom
Nicolas Dechesne
Lucas Stach
Emil Velikov
Samuel Pitoiset
Rhys Kidd
Iago Toral Quiroga