| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This enables support for importing RGBX8888 EGLImage textures on
Skylake.
Chrome OS needs support for RGBX8888 EGLImage textures because because
the Android framework produces HAL_PIXEL_FORMAT_RGBX8888 winsys
surfaces, which the Chrome OS compositor consumes as dma_bufs. On
hardware for which RGBX is unsupported or disabled, normally core Mesa
provides the RGBX->RGBA fallback during glTexStorage. But the DRIimage
code bypasses core Mesa, so we must do the fallback in i965.
Reviewed-by: Kenneth Graunke <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
| |
src/mesa/drivers/x11/xm_dd.c:688:7: warning: implicit declaration of function ‘_mesa_update_draw_buffer_bounds’; did you mean ‘_mesa_has_ARB_draw_buffers_blend’? [-Wimplicit-function-declaration]
_mesa_update_draw_buffer_bounds(ctx, ctx->DrawBuffer);
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Cc: Marek Olšák <[email protected]>
Fixes: 585c5cf8a514783d9ed3 ("mesa: don't update draw buffer bounds in
_mesa_update_state")
Signed-off-by: Eric Engestrom <[email protected]>
|
|
|
|
|
| |
Signed-off-by: Lionel Landwerlin <[email protected]>
Acked-by: Kenneth Graunke <[email protected]>
|
|
|
|
|
| |
Signed-off-by: Lionel Landwerlin <[email protected]>
Acked-by: Kenneth Graunke <[email protected]>
|
|
|
|
|
| |
Signed-off-by: Lionel Landwerlin <[email protected]>
Reviewed-by: Kenneth Graunke <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
From experimentation in IGT, we found that the OA unit might label
some report as "idle" (using an invalid context ID), right after a
report for a given context. Deltas generated by those reports actually
belong to the previous context, even though they're not labelled as
such.
This change makes ensure that while reading OA reports, we only
consider the GPU actually idle after 2 reports with an invalid context
ID.
Signed-off-by: Lionel Landwerlin <[email protected]>
Reviewed-by: Kenneth Graunke <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Due to an underlying hardware race condition, we have no guarantee
that all the reports coming from the OA buffer related to the workload
we're trying to measure have landed to memory by the time all the work
submitted has completed. That means we need to keep on reading the OA
stream until we read a report with a timestamp more recent than the
timestamp recored by the MI_REPORT_PERF_COUNT at the end of the
performance query.
v2: fix uninitialized offset variable to 0 (Lionel)
v3: rework the reading to avoid blocking the user of the API unless
requested (Rob)
v4: fix a bug that makes the i965 driver reading the perf stream when
not necessary, leading to very long counter accumulation times
(Lionel)
Signed-off-by: Lionel Landwerlin <[email protected]>
Reviewed-by: Kenneth Graunke <[email protected]>
|
|
|
|
|
|
|
|
|
|
| |
Enables access to OA unit metrics on Gen8+ via INTEL_performance_query.
v2: make use of new parameters coming from gen_device_info (Lionel)
Signed-off-by: Robert Bragg <[email protected]>
Signed-off-by: Lionel Landwerlin <[email protected]>
Reviewed-by: Kenneth Graunke <[email protected]>
|
|
|
|
|
|
|
|
| |
Also updates Makefile.am to generate corresponding normalization code.
Signed-off-by: Robert Bragg <[email protected]>
Acked-by: Lionel Landwerlin <[email protected]>
Reviewed-by: Kenneth Graunke <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
| |
In preparation for adding XML OA metric set descriptions for Gen 8 and 9
which will result in auto generated code that depends on a number of new
system variables ($EuSubslicesTotalCount, $EuThreadsCount and
$SliceMask) this adds corresponding members to brw->perf.sys_vars.
Signed-off-by: Robert Bragg <[email protected]>
Reviewed-by: Lionel Landwerlin <[email protected]>
Reviewed-by: Kenneth Graunke <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
With Ken's work to drop the library dependency on libdrm_intel, we now
only depend on libdrm for the kernel uapi headers it provides. It
seems like we're better off just embeddeding those headers ourselves,
making the lives of people developping news features tightly
integrated with the kernel a tiny bit easier.
This change also makes it a bit more obvious what cflags/libs are
required by the i915 drivers vs i965, by renaming INTEL_CFLAGS/LIBS
into I915_CFLAGS/LIBS.
Headers were generated from drm-tip on the following commit :
commit 6d61e70ccc21606ffb8a0a03bd3aba24f659502b
Merge: 338ffbf7cb5e c0bc126f97fb
Author: Dave Airlie <[email protected]>
Date: Tue Jun 27 07:24:49 2017 +1000
Backmerge tag 'v4.12-rc7' into drm-next
v2: Use installed files from the kernel (Daniel Vetter)
v3: Use headers from drm-next rather than drm-tip (Dave/Daniel)
Signed-off-by: Lionel Landwerlin <[email protected]>
Acked-by: Jason Ekstrand <[email protected]>
Reviewed-by: Kenneth Graunke <[email protected]>
|
|
|
|
|
|
| |
Signed-off-by: Lionel Landwerlin <[email protected]>
Reviewed-by: Kenneth Graunke <[email protected]>
Reviewed-by: Emil Velikov <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
| |
Counter related to timings will be sensitive to any delay introduced
by the software. In particular if our begin & end of performance
queries end up in different batches, time related counters will
exhibit biffer values caused by the time it takes for the kernel
driver to load new requests into the hardware.
Signed-off-by: Lionel Landwerlin <[email protected]>
Acked-by: Kenneth Graunke <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
| |
Makes coverity happier.
Fix indentation in gen >= 8 block while at it.
CID: 1413020
Reviewed-by: Kenneth Graunke <[email protected]>
Reviewed-by: Eric Engestrom <[email protected]>
Signed-off-by: Topi Pohjolainen <[email protected]>
|
|
|
|
|
| |
Signed-off-by: Ian Romanick <[email protected]>
Reviewed-by: Ville Syrjälä <[email protected]>
|
|
|
|
|
| |
Signed-off-by: Ian Romanick <[email protected]>
Reviewed-by: Ville Syrjälä <[email protected]>
|
|
|
|
|
| |
Signed-off-by: Ian Romanick <[email protected]>
Reviewed-by: Ville Syrjälä <[email protected]>
|
|
|
|
|
| |
Signed-off-by: Ian Romanick <[email protected]>
Reviewed-by: Ville Syrjälä <[email protected]>
|
|
|
|
|
| |
Signed-off-by: Ian Romanick <[email protected]>
Reviewed-by: Ville Syrjälä <[email protected]>
|
|
|
|
|
| |
Signed-off-by: Ian Romanick <[email protected]>
Reviewed-by: Ville Syrjälä <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Meta always sets the API to API_OPENGL_COMPAT, so the current API
setting is irrelevant.
text data bss dec hex filename
7154994 256860 37332 7449186 71aa62 32-bit i965_dri.so before
7154978 256860 37332 7449170 71aa52 32-bit i965_dri.so after
6788451 328056 50704 7167211 6d5ceb 64-bit i965_dri.so before
6788419 328056 50704 7167179 6d5ccb 64-bit i965_dri.so after
Signed-off-by: Ian Romanick <[email protected]>
Reviewed-by: Ville Syrjälä <[email protected]>
|
|
|
|
|
|
|
|
|
|
| |
Performance deltas:
Alien Isolation: +17% (it varies depending on the location)
Borderlands 2: +50% (it varies depending on the location)
BioShock Infinite: +76% (benchmark)
Civilization 6: +20% (benchmark)
Reviewed-by: Timothy Arceri <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This commit replaces the complex and confusing set of disable flags with
two fairly straightforward fields which describe the intended auxiliary
surface usage and whether or not the miptree supports fast clears.
Right now, supports_fast_clear can be entirely derived from aux_usage
but that will not always be the case.
This commit makes functional changes. One of these changes is that it
re-enables multisampled fast-clears which were accidentally disabled in
cec30a666930ddb8476a9452a89364a24979ff62 around a year ago. Fixing this
improves the SynMark v7 DeferredAA test by around ~3% on some gen9
hardware. This commit also gets us closer to enabling CCS_E for
window-system buffers which are Y-tiled.
Reviewed-by: Chad Versace <[email protected]>
Reviewed-by: Topi Pohjolainen <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
| |
Starting with Sky Lake, we can clear to arbitrary floats or integers.
Unfortunately, the hardware isn't particularly smart when it comes
sampling from that clear color. If the clear color is out of range for
the surface format, it will happily return whatever we put in the
surface state packet unmodified. In order to avoid returning bogus
values for surfaces with a limited range, we need to do some clamping.
Cc: "17.1" <[email protected]>
Reviewed-by: Chad Versace <[email protected]>
|
|
|
|
|
|
| |
This function is only used on gen4-5 which don't support HiZ.
Reviewed-by: Chad Versace <[email protected]>
|
|
|
|
|
|
|
| |
While we're here, we also make the two support checks static since there
are no users outside intel_mipmap_tree.c.
Reviewed-by: Chad Versace <[email protected]>
|
|
|
|
|
|
|
|
|
| |
We never fast-clear more than the base slice (LOD 0, layer 0) anyway, so
layered rendering without a resolve is always perfectly safe. Should
this ever change in the future, we'll have to put some sort of resolve
back in but we can cross that bridge when we come to it.
Reviewed-by: Chad Versace <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
| |
With below optimizations gone in gen10+ we have nothing left out to
write to CACHE_MODE_1:
Float Blend Optimization Enable: This bit have been removed in gen10+
Partial Resolve Disable in VC: Recommendation is to always set this
field to 0 in gen10+ and that's the default value of the bit.
Signed-off-by: Anuj Phogat <[email protected]>
Reviewed-by: Kenneth Graunke <[email protected]>
|
|
|
|
|
|
|
|
| |
This fixes the long-standing problem with black transitions in The Wicher 2.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=98238
Signed-off-by: Marek Olšák <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This needs to be passed to gallium drivers.
No game fix is planned at this time.
The addition of glsl_correct_derivatives_after_discard is
generally a good thing for mesa compatibility with the broader GL
driver ecosystem.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=100070
Reviewed-by: Nicolai Hähnle <[email protected]>
|
|
|
|
|
|
|
|
|
|
| |
This function was moved to genX_state_upload.c but was still not using genxml.
By converting it to genxml, we make some things simpler, like setting
haswell's border color state, but others are more complex, since the structs
used by each gen are different.
Signed-off-by: Rafael Antognolli <[email protected]>
Reviewed-by: Lionel Landwerlin <[email protected]>
|
|
|
|
|
|
|
|
| |
The sampler state code was all moved to genxml, so we can get rid of these
functions and delete the file.
Signed-off-by: Rafael Antognolli <[email protected]>
Reviewed-by: Lionel Landwerlin <[email protected]>
|
|
|
|
|
|
|
|
| |
Since they just use the code that is already available in genX_state_upload.c,
convert them in one batch.
Signed-off-by: Rafael Antognolli <[email protected]>
Reviewed-by: Lionel Landwerlin <[email protected]>
|
|
|
|
|
|
|
|
| |
Also convert some auxiliary functions used by it, and copy
upload_default_color to genX_state_upload.c.
Signed-off-by: Rafael Antognolli <[email protected]>
Reviewed-by: Lionel Landwerlin <[email protected]>
|
|
|
|
| |
Trivial fix. 'ctx' was unused.
|
|
|
|
|
|
|
| |
The param is currently unused. It will later be used it to support
R8G8B8X8 EGLConfigs on Skylake.
Reviewed-by: Kenneth Graunke <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This allows us to query the driver's supported formats in i965's DRI code,
where often there is available a DRIscreen but no GL context.
To reduce diff noise, this patch does not completely remove
brw_context's format arrays. It just redeclares them as pointers which
point to the arrays in intel_screen.
Specifically, move these two arrays from brw_context to intel_screen:
mesa_to_isl_render_format[]
mesa_format_supports_render[]
And add a new array to intel_screen,
mesa_format_supportex_texture[]
which brw_init_surface_formats() copies to ctx->TextureFormatSupported.
Reviewed-by: Kenneth Graunke <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
I'm swimming in a vortex of formats. Mesa formats, isl formats, DRI
formats, GL formats, etc.
It's easy to misinterpret the following brw_context members unless
you've recently read their definition. In upcoming patches, I change
them from embedded arrays to simple pointers; after that, even their
definition doesn't help, because the MESA_FORMAT_COUNT hint will no
longer be present.
Rename them to prevent further confusion. While we're renaming, choose
shorter names too.
-format_supported_as_render_target
+mesa_format_supports_render
-render_target_format
+mesa_to_isl_render_format
Reviewed-by: Kenneth Graunke <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
gl_FragCoord contains the window coordinates so it seems to me that
we should not use perspective correct interpolation for it. At least
now I get similar output as i965/swrast/llvmpipe produce.
This fixes dEQP-GLES2.functional.shaders.builtin_variable.fragcoord_w.
dEQP-GLES2.functional.shaders.builtin_variable.fragcoord_xyz was already
passing, though I'm not quite sure how it managed to do that.
v2: Add definitons for the S3 "wrap shortest" bits as well (Ian)
Cc: [email protected]
Reviewed-by: Ian Romanick <[email protected]>
Signed-off-by: Ville Syrjälä <[email protected]>
|
|
|
|
|
|
|
|
| |
not used
Reviewed-by: Nicolai Hähnle <[email protected]>
Reviewed-by: Brian Paul <[email protected]>
Reviewed-by: Timothy Arceri <[email protected]>
|
|
|
|
|
|
|
|
| |
These are only used in the GL compatibility profile.
Reviewed-by: Nicolai Hähnle <[email protected]>
Reviewed-by: Brian Paul <[email protected]>
Reviewed-by: Timothy Arceri <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
st/mesa doesn't need the draw bounds for draw calls. I've added the call
where it's necessary in core Mesa and drivers, but I suspect that most
drivers can just move the call to the right places.
The core Mesa places aren't hot paths, so the call overhead doesn't matter
there.
For now, only st/mesa is made such that this function is invoked very
rarely.
Reviewed-by: Nicolai Hähnle <[email protected]>
Reviewed-by: Brian Paul <[email protected]>
Reviewed-by: Timothy Arceri <[email protected]>
|
|
|
|
|
|
| |
Reviewed-by: Nicolai Hähnle <[email protected]>
Reviewed-by: Brian Paul <[email protected]>
Reviewed-by: Timothy Arceri <[email protected]>
|
|
|
|
|
|
| |
Reviewed-by: Nicolai Hähnle <[email protected]>
Reviewed-by: Brian Paul <[email protected]>
Reviewed-by: Timothy Arceri <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The idea is to remove the dependency on _mesa_update_state_locked,
so that st/mesa can skip it for stencil state updates, and then stop
setting _NEW_STENCIL in mesa/main if the driver is st/mesa.
The main motivation is to stop invoking _mesa_update_state_locked for
certain state groups.
Reviewed-by: Nicolai Hähnle <[email protected]>
Reviewed-by: Brian Paul <[email protected]>
Reviewed-by: Timothy Arceri <[email protected]>
|
|
|
|
|
|
|
|
|
|
| |
_mesa_update_state will no longer recompute Width/Height if the framebuffer
is complete. We now rely on the FBO completeness check to do it.
The only code that needs to be fixed seems to be this one.
Reviewed-by: Ian Romanick <[email protected]>
Tested-by: Ian Romanick <[email protected]>
|
|
|
|
|
|
|
|
| |
Fixes dEQP-EGL.functional.image.render_multiple_contexts.
gles2_renderbuffer_stencil_stencil_buffer
Signed-off-by: Topi Pohjolainen <[email protected]>
Reviewed-by: Jason Ekstrand <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
These locks were added in 2f28a0dc, but I don't see anything in the
intel_miptree_blit path that should make this necessary.
When asked, Kristian says:
I doubt it's needed now with the new blorp. If I remember correctly,
I had to drop the lock there since intel_miptree_blit() could hit
the XY blit path that requires a fast clear resolve. The fast
resolve being meta, would then try to lock the texture again.
Signed-off-by: Ian Romanick <[email protected]>
Reviewed-by: Kristian Høgsberg <[email protected]>
|
|
|
|
|
|
|
| |
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=101535
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=101538
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=101539
Reviewed-by: Topi Pohjolainen <[email protected]>
|
|
|
|
|
|
|
|
|
|
| |
On gen6+, this is called "Dispatch GRF Start Register For Constant/Setup Data
0", while on gen5 and lower it's called only "Dispatch GRF Start Register For
URB Data", but it's essentially the same thing (URB data), so rename it to
match newer gens and simplify the C code that handles it.
Signed-off-by: Rafael Antognolli <[email protected]>
Reviewed-by: Kenneth Graunke <[email protected]>
|