This macro was needed by meta in order to make gen-specific calls from
gen-agnostic code. Now that we don't have meta, the remaining two uses are
fairly trivial to get rid of.
Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
Now that we no longer have meta, all pipelines get created via the normal
Vulkan pipeline creation mechanics. There is no more need for this bit of
extra magic data that we've been passing around.
Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
Reviewed-by: Topi Pohjolainen <topi.pohjolainen@intel.com>
If we don't, we can end up with corruption in the portion of the depth
buffer that lies outside the render area when we do a HiZ resolve at the
end. The only reason we weren't seeing this before was that all of the
meta-based clears such as VkCmdClearDepthStencilImage were internally using
HiZ so the HiZ buffer never truly got out-of-sync. If the CTS ever tested
a depth upload (which doesn't care about HiZ) and then a partial render we
would have seen problems. Soon, we will be using blorp to do depth clears
and it won't bother with HiZ so we would get CTS regressions without this.
Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
Reviewed-by: Nanley Chery <nanley.g.chery@intel.com>
When I initially brought up Vulkan blorp, I completely missed that this
was already factored out. There's no good reason for us to hand-roll it.
Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
Reviewed-by: Topi Pohjolainen <topi.pohjolainen@intel.com>
In Vulkan, we want to be able to use blorp to perform clears inside of a
render pass. If blorp stomps the depth/stencil buffers packets then we'll
have to re-emit them. This gets tricky when secondary command buffers get
involved. Instead, we'll simply guarantee that the depth and stencil
buffers we pass to blorp (if any) match those already set in the hardware.
Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
Reviewed-by: Topi Pohjolainen <topi.pohjolainen@intel.com>
This never mattered before because the only time we used blorp
depth/stencil only was to do HiZ operations on gen6-7. It may have worked
in that case (and maybe it didn't) but slow depth clears actually do depth
rendering so they need a valid render target.
Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
Reviewed-by: Topi Pohjolainen <topi.pohjolainen@intel.com>
This gives a slightly smarter way to check whether or not a particular
surface exists than looking at the address.
Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
Reviewed-by: Topi Pohjolainen <topi.pohjolainen@intel.com>
This should now set the pipeline up properly for doing depth and/or stencil
clears by plumbing through depth/stencil test values. We are now also
emitting color calculator state for blorp operations without an actual
shader because that is where the stencil reference value goes pre-SKL.
Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
Reviewed-by: Topi Pohjolainen <topi.pohjolainen@intel.com>
The newly reworked depth/stencil config code can properly handle having
depth, stencil, both, or neither. We no longer need to predicate it on
having depth or stencil.
Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
Reviewed-by: Topi Pohjolainen <topi.pohjolainen@intel.com>
While we're here, we also make depth without HiZ work.
v2:
- Use the correct surface type for 1-D on SKL+
- Set QPitch on BDW+
Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
Reviewed-by: Topi Pohjolainen <topi.pohjolainen@intel.com>
We want to be able to start doing slow depth clears with blorp. This
allows us to adjust the depth we're clearing to.
Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
Reviewed-by: Topi Pohjolainen <topi.pohjolainen@intel.com>
Due to conflicting symbol names (between i915 and i965) in the
megadriver, we use a set of defines in i915/intel_screen.h.
With a recent commit we've introduced a symbol intelFenceExtension which
has different implementation for each driver, yet we forgot to add the
define.
Fixes: d11515ff1b ("i915/sync: Implement DRI2_Fence extension")
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=98264
Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
Document the EGL enum ranges for Mesa and those values allocated by the
following extensions:
EGL_MESA_drm_image
EGL_MESA_platform_gbm
EGL_MESA_platform_surfaceless
EGL_WL_bind_wayland_display
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
Years ago Khronos replaced the registry's spec files with newfangled XML
files. Update the reference in doc/specs/enum.txt accordingly.
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
It was the lone file in src/egl/docs. Move it to where the other specs
live, in $MESA_TOP/docs/specs.
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
Mesa's set of supported platform extensions depends on the autoconf
option --with-egl-platforms=foo,bar,baz. If --with-egl-platforms lacks
foo, then eglGetPlatformDisplay(EGL_PLATFORM_FOO, ...) unconditonally
fails.
So, if --with-egl-platforms lacks foo, then remove
EGL_VENDOR_platform_foo from the EGL client extension string.
Cc: mesa-stable@lists.freedesktop.org
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
modulefinder wasn't searching for dependencies in the script dir.
It's not capable of detecting the sys.path manipulations scripts do
internally neither.
This change fixes the first issue, and hacks around the second.
Honestly, I've come to the conclusion that automatic Python dependency it will always be
too brittle. I think we should start manually typing the dependencies
like we do in automake. At very least it will enable any person to
eyeball and spot/fix missing dependencies, without dig into SCons internals.
Porting of the corresponding patch for i965.
Here follows the original commit message by Tomasz Figa:
"As the spec allows for {server,client}_wait_sync to be called without
currently bound context, while our implementation requires context
pointer.
v2: Add a mutex and acquire it for the duration of
brw_fence_client_wait() and brw_fence_is_completed() as suggested
by Chad."
NOTE: in i915 all references to 'brw' are replaced by 'intel'
Marshmallow-x86 boots ok with the following results of Android CTS.
Android CTS 6.0_r7 build:2906653
Session Pass Fail Not Executed
0(EGL) 1410 24 0
1(GLES2) 13832 82 0
I get the same results as per i965GM.
[Emil Velikov: Include Mauro's test results]
Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
Here is the porting of corresponding patch for i965,
i.e. commit c636284 i965/sync: Implement DRI2_Fence extension
Here follows part of original commit message by Chad Versace:
"This enables EGL_KHR_fence_sync and EGL_KHR_wait_sync."
Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
This is the porting of corresponding patch for i965,
i.e. commit 2516d83 i965/sync: Replace prefix 'intel_sync' -> 'intel_gl_sync'
The only difference compared to i965 one is that intel_check_sync() was renamed
to intel_gl_check_sync() here, as it is more appropriate.
Here follows original commit message by Chad Versace:
"I'm about to implement DRI2_Fenc in intel_syncobj.c. To prevent
madness, we need to prefix functions for GL_ARB_sync with 'gl' and
functions for DRI2_Fence with 'dri'. Otherwise, the file will become
a jumble of similiarly named functions.
For example:
old-name: intel_client_wait_sync()
new-name: intel_gl_client_wait_sync()
soon-to-come: intel_dri_client_wait_sync()
I wrote this renaming commit separately from the commit that implements
DRI2_Fence because I wanted the latter diff to be reviewable."
[Emil Velikov: rename the outstanding intel_sync instances]
Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
... in dri2_x11_add_configs_for_visuals().
Currently the latter does not consider that, thus in such cases it adds
"empty" configs in the list.
Properly account for things and as we do that we can reuse count,
instead of calling _eglGetArraySize to determine if we've added any
configs.
Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
Reviewed-by: Eric Engestrom <eric@engestrom.ch>
Analogous to previous commits - with an extra bonus.
Current code, apart from not attributing the lack of 'per visual'
and overall configs also overwrites the newly added config.
Namely if the dpy supports two or more of the supported formats
(XRGB8888, ARGB8888 and RGB565) earlier configs will be overwritten
and the the final one will be stored, since the we use the same index
for all three in our dri2_add_config call.
v2: Use correct comparison in loop conditional (Eric)
Use valid C initializer (Gurchetan)
Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
Reviewed-by: Eric Engestrom <eric@engestrom.ch>
Analogous to previous commit.
v2: Use correct comparison in loop conditional (Eric)
Use valid C initializer (Gurchetan)
Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
Reviewed-by: Gurchetan Singh <gurchetansingh@chromium.org>
Reviewed-by: Eric Engestrom <eric@engestrom.ch>
Iterate over the driver_configs first in order to cut down the number of
getConfigAttrib() calls by a factor of 5.
While we're here, also drop the sentinel of the visuals array. We
already know its size so we can use that and save a few bytes.
v2: Use correct comparison in loop conditional (Eric)
Use valid C initializer (Gurchetan)
Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
Reviewed-by: Eric Engestrom <eric@engestrom.ch>
Factor out and rework the existing code so that it prints a debug
message if we have zero configs for any visual.
As a nice side effect we now provide a correct (sequential ID) when
creating a config (via dri2_add_config).
v2: Use correct comparison in loop conditional (Eric)
Use valid C initializer (Gurchetan)
Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
Reviewed-by: Eric Engestrom <eric@engestrom.ch>
Currently we print a debug message if the total configs is non-zero only
to do the same (at an error level) as we return from the function.
Rework the message to print if we're missing a config for the given
format.
Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
Reviewed-by: Gurchetan Singh <gurchetansingh@chromium.org>
Reviewed-by: Eric Engestrom <eric@engestrom.ch>
Introduce a helper and use it throughout the platform code. This allows
us to reduce the amount of ifdef(s) and (potentially) use
kms_swrast_dri.so for !drm platforms (namely wayland and x11).
Note: in the future as other platforms (android, surfaceless) support
the extension they can reuse the helper.
v2: Rebase, check for device_name.
Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
Reviewed-by: Daniel Stone <daniels@collabora.com>
Reviewed-by: Eric Engestrom <eric@engestrom.ch>
The core egl/dri2 already sets the extension bit _only_ when possible -
which in Android's case is always.
Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
Do not loop over all matches if we've already found one.
Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
Reviewed-by: Eric Engestrom <eric@engestrom.ch>
v2: dri2_bind_extensions() now takes optional as an argument.
Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
Reviewed-by: Eric Engestrom <eric@engestrom.ch>
