This is a revert of Marek's 84f3afc2e1 revert, with a missing
line added back. I failed a rebase and dropped that crucial line, and
didn't do a runtime test after my rebase, and as a result broke EGL for
everyone.
This commit has been tested by Intel's CI and I re-read it once more, so
it should be good this time.
--
Note: dropping the EGL_BAD_ALLOC in egl_haiku because it's
overwritten by the EGL_NOT_INITIALIZED in eglInitialize().
Signed-off-by: Eric Engestrom <eric@engestrom.ch>
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
This reverts commit 773d6ea6e7.
Since kernel 4.17 (drm/etnaviv: remove the need for a gpu-subsystem DT
node) the etnaviv DRM driver doesn't have an associated DT node
anymore. This is technically correct, as the etnaviv device is a
virtual device driving multiple hardware devices.
Before 4.17 the userspace had access to the following information:
DRIVER=etnaviv
OF_NAME=gpu-subsystem
OF_FULLNAME=/gpu-subsystem
OF_COMPATIBLE_0=fsl,imx-gpu-subsystem
OF_COMPATIBLE_N=1
MODALIAS=of:Ngpu-subsystemT<NULL>Cfsl,imx-gpu-subsystem
DRIVER=imx-drm
OF_NAME=display-subsystem
OF_FULLNAME=/display-subsystem
OF_COMPATIBLE_0=fsl,imx-display-subsystem
OF_COMPATIBLE_N=1
Afer 4.17:
DRIVER=etnaviv
MODALIAS=platform:etnaviv
The OF node has never been part of the etnaviv UABI, simply due to the
fact that it's still possible to instantiate the etnaviv driver from a
platform file, instead of a devicetree node.
A patch set to fix this problem was send out [1] but it looks like
that a proper solution needs more time to bake.
[1] https://lists.freedesktop.org/archives/dri-devel/2018-October/194651.html
Suggested-by: Emil Velikov <emil.l.velikov@gmail.com>
Signed-off-by: Christian Gmeiner <christian.gmeiner@gmail.com>
I don't think we want to wait for something that hasn't been
correctly submitted. This is similar to the fallback path.
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Reviewed-by: Dave Airlie <airlied@redhat.com>
This isn't true for Vulkan so we have to whack it to "main" in anv which
is silly. Instead of walking the list of functions and asserting that
everything is named "main" and hoping there's only one function named
"main", just use the nir_shader_get_entrypoint() helper which has better
assertions anyway.
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
ffs() just returns the bit that is set, we need to know what
stage that bit represents so use u_bit_scan() instead.
Fixes: 2ca5d9548f ("st/glsl_to_nir: gather next_stage in shader_info")
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
This isn't used in mesa, maybe vmware uses this in a closed source state
tracker?
Tested-by: Brian Paul <brianp@vmware.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
In order to pull u_debug into src/util we need to break the generically
useful bits from the bits that are tightly coupled to gallium.
Tested-by: Brian Paul <brianp@vmware.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
amdgpu doesn't use the INPUT but the AVERAGE subfeature:
$ sensors -u
amdgpu-pci-0100
Adapter: PCI adapter
power1:
power1_average: 17.233
power1_cap: 180.000
Signed-off-by: Andre Heider <a.heider@gmail.com>
Signed-off-by: Marek Olšák <marek.olsak@amd.com>
TGSI has no I64MAD/U64MAD opcode.
Fixes: 278580729a ('st/glsl_to_tgsi: add support for 64-bit integers')
Signed-off-by: Rhys Perry <pendingchaos02@gmail.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Dual source blending behaviour is undefined when shader doesn't
have second color output.
"If SRC1 is included in a src/dst blend factor and
a DualSource RT Write message is not used, results
are UNDEFINED. (This reflects the same restriction in DX APIs,
where undefined results are produced if “o1” is not written
by a PS – there are no default values defined)."
Dismissing fragment in such situation leads to a hang on gen8+
if depth test in enabled.
Since blending cannot be gracefully fixed in such case and the result
is undefined - blending is simply disabled.
v2 (Jason Ekstrand):
- Apply the workaround to each individual entry
- Emit a warning through debug_report
Signed-off-by: Danylo Piliaiev <danylo.piliaiev@globallogic.com>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Dual source blending behaviour is undefined when shader doesn't
have second color output, dismissing fragment in such situation
leads to a hang on gen8+ if depth test in enabled.
Since blending cannot be gracefully fixed in such case and the result
is undefined - blending is simply disabled.
v2 (Kenneth Graunke):
- Listen to BRW_NEW_FS_PROG_DATA in 3DSTATE_PS_BLEND
- Also whack BLEND_STATE[] to keep the two in sync, since we're not
sure exactly which copy of the redundant info the hardware will use.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107088
Signed-off-by: Danylo Piliaiev <danylo.piliaiev@globallogic.com>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Apparently, we're supposed to look at the texture object's built-in
sampler object's sRGB decode setting in order to decide whether to
decode/downsample/re-encode, or simply downsample as-is. Previously,
I had always done the decoding/encoding.
Fixes SKQP's Skia_Unit_Tests.SRGBMipMaps test.
Reviewed-by: Tapani Pälli <tapani.palli@intel.com>
If we restore the 'new batch' using 'intel_batchbuffer_reset_to_saved'
function we must restore the default state of the batch using
'brw_new_batch' function because the 'intel_batchbuffer_flush'
function will not do it for the 'new batch' again.
At least the following fields of the batch
'state_base_address_emitted','aperture_space', 'state_used'
should be restored to default values to avoid:
1. the aperture_space overflow
2. the missed STATE_BASE_ADDRESS commad in the batch
3. the memory overconsumption of the 'statebuffer'
due to uncleared 'state_used' field.
etc.
v2: merge with new commits, changes was minimized, added the 'fixes' tag
v3: added in to patch series
Fixes: 3faf56ffbd "intel: Add an interface for saving/restoring
the batchbuffer state."
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107626
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
There's no point reverting to the last saved point if that save point is
the empty batch, we will just repeat ourselves.
CC: Chris Wilson <chris@chris-wilson.co.uk>
Fixes: 3faf56ffbd "intel: Add an interface for saving/restoring
the batchbuffer state."
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107626
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
While at it, turn "unreachable" assert() into unreachable().
Signed-off-by: Eric Engestrom <eric.engestrom@intel.com>
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
This was required back when MSVC didn't support C99 and was missing this
header, but since MSVC 2013 (or maybe earlier?) this isn't it does and
this code isn't doing anything anymore.
Signed-off-by: Eric Engestrom <eric.engestrom@intel.com>
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
Fixes: 6ccc435e7a "pipe-loader: move dup(fd) within pipe_loader_drm_probe_fd"
Signed-off-by: Eric Engestrom <eric.engestrom@intel.com>
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
We were doing this late after nir_lower_io, but we can just reuse the core
code. By doing it at this stage, we won't even set up the VS attributes
as inputs, reducing our VPM size.
We always emit 4 slots per slot because things like color output and
position processing in the epilogue will potentially look up more values
than the variable declaration had. However, when we get a .location_frac
!= 0, we don't want to overwrite components of the following
.driver_location.
For supporting scalar VPM i/o at the NIR level, we need to do a pass over
the vars to figure out how big each attribute is after DCE. Once we've
done that, we can just walk over c->vattr_sizes[] instead of bothering
with vars.
