Currently pipe_loader_drm_probe_fd takes ownership of the fd given.
To match that, pipe_loader_release closes it.
Yet we have many instances which do not want the change of ownership,
and thus duplicate the fd before passing it to the pipe-loader.
Move the dup() within pipe-loader, explicitly document that and document
all the cases through the codebase.
A trivial git grep -2 pipe_loader_release makes things as obvious as it
gets ;-)
Cc: Leo Liu <leo.liu@amd.com>
Cc: Thomas Hellstrom <thellstrom@vmware.com>
Cc: Axel Davy <davyaxel0@gmail.com>
Cc: Patrick Rudolph <siro@das-labor.org>
Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
Reviewed-by: Thomas Hellstrom <thellstrom@vmware.com>
Reviewed-by: Axel Davy <davyaxel0@gmail.com> (for nine)
As the newly introduced comment says:
The pipe loader takes ownership of the fd
Thus, there's no need to close it again.
Cc: Patrick Rudolph <siro@das-labor.org>
Cc: Axel Davy <davyaxel0@gmail.com>
Cc: mesa-stable@lists.freedesktop.org>
Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
Reviewed-by: Axel Davy <davyaxel0@gmail.com>
Earlier commit added support for 'front_buffers', erroneously adding a
return in vl_dri3_screen_destroy. Effectively leaking a lot of state.
Fixes: 8d7ac0a4e4 ("vl/dri3: implement DRI3 BufferFromPixmap")
Cc: Leo Liu <leo.liu@amd.com>
Cc: Christian König <christian.koenig@amd.com>
Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
Reviewed-by: Leo Liu <leo.liu@amd.com>
The header was used only by dri2.c, containing a two-member struct and cast wrapper.
Just inline it where it's used/needed.
Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
Reviewed-by: Eric Engestrom <eric.engestrom@intel.com>
As discussed in the review of the patch which added the comment:
Nothing happens when a thread is created, because pthread_atfork doesn't
affect creating threads. However, spawning a child process will likely
crash.
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Pulling this logic out means we can share the logic and avoid a couple
of temporary variables that helped make things clearer before. Note
that in either vismode case, we always program vismode 0.
Signed-off-by: Kristian H. Kristensen <hoegsberg@chromium.org>
Now that we've copied the emit logic into each branch of the
if (info->index_size) statement, we can simplify the logic a bit
according to which case we're in.
Signed-off-by: Kristian H. Kristensen <hoegsberg@chromium.org>
This splits the two code paths into separate functions and moves the
"if (info->indirect)" test into draw_impl().
Signed-off-by: Kristian H. Kristensen <hoegsberg@chromium.org>
This way the markers clearly bracket the draw call and isn't
duplicated for both direct and indirect draw code.
Signed-off-by: Kristian H. Kristensen <hoegsberg@chromium.org>
According to the following definition,
int AtomicCompSwap(inout int mem, uint compare, uint data);
the preceding one in atomic_comp_swap of NIR is compare and data is
followed, while src0 for cmpxchg needs vec2(data, compare)
So for ssbo/image deref comp_swap, that should be reversed.
Fixes: dEQP-GLES31.functional.image_load_store.*.atomic.comp_swap*
Possibly these bits mean something else now. Blob always seems to use
FOUR_QUADS, and changing to TWO_QUADS seems to cause different threads
to overlap registers.
Signed-off-by: Rob Clark <robdclark@gmail.com>
Fix a few bits of confusion, as with previous gen's constlen is aligned
to 4, and value in bitfield is left-shifted by 2 (ie. divided by 4).
But this is done by the CONSTLEN() accessor/builder fxn, so don't do it
twice. Also HLSQ_FS_CNTL.CONSTLEN is not special.
Signed-off-by: Rob Clark <robdclark@gmail.com>
batch_flush_reset_dependencies() expects to be called unlocked, and can
call fd_batch_reference() which can try to aquire the screen lock again.
Signed-off-by: Rob Clark <robdclark@gmail.com>
In c3d9f29b we allowed ctx->batch to be null, and started tracking the
current framebuffer state in fd_context. But the existing logic in
fd_blitter_pipe_begin() would, if !ctx->batch, set null fb state to be
restored after blit. Which broke the world of deqp (and probably other
things)
Fixes: c3d9f29b78 freedreno: allocate ctx's batch on demand
Signed-off-by: Rob Clark <robdclark@gmail.com>
This is defined to always clear the entire surface(s) specified,
regardless of scissor state.. mesa/st will turn scissored clears
into a draw. So rip about a bunch of unnecessary machinery.
Also remove a comment that was obsolete since using u_blitter to
turn clear into draw (for the cases where there isn't a hw blitter
fast-path).
Signed-off-by: Rob Clark <robdclark@gmail.com>
The logic to force a flush every draw was short-circuited with newer
kernels. Also it should apply to clears as well.
Signed-off-by: Rob Clark <robdclark@gmail.com>
The effective scissor changes based on rasterizer->scissor flag, so we
need to re-emit scissor state when rasterizer state changes.
Signed-off-by: Rob Clark <robdclark@gmail.com>
Previously if only ff vs or only ff ps was used,
the constants for both were marked as updated,
while only the constants of the used ff shader
were updated.
Now that NINE_STATE_FF_VS and
NINE_STATE_FF_PS do not intersect anymore,
we can correctly mark the correct set of constant
as updated.
Fixes: https://github.com/iXit/Mesa-3D/issues/319
Signed-off-by: Axel Davy <davyaxel0@gmail.com>
NINE_STATE_FF_OTHER was mostly ff vs states.
Rename it to NINE_STATE_FF_VS_OTHER and
move common states with ps to
NINE_STATE_FF_PS_CONSTS (renamed from
NINE_STATE_FF_PSSTAGES).
Signed-off-by: Axel Davy <davyaxel0@gmail.com>
Some states only affect the ff shader,
not its constants.
Currently we don't check anything and
always recompute the ff shader key.
However we do check for NINE_STATE_FF_OTHER
and if set we reupload some constants.
Thus for those states which had NINE_STATE_FF_OTHER
set but didn't need it,
replace by a dummy ff shader state (which is
easier to understand for an external reader than
just setting 0 and more future proof).
Signed-off-by: Axel Davy <davyaxel0@gmail.com>
The pointsize states were missing the ff
NINE_STATE_FF_OTHER flag, and thus might
miss state updates when using ff.
Fixes some wine tests.
Signed-off-by: Axel Davy <davyaxel0@gmail.com>
Rename NINE_STATE_FOG_SHADER,
NINE_STATE_POINTSIZE_SHADER and NINE_STATE_PS1X_SHADER
into
NINE_STATE_VS_PARAMS_MISC and NINE_STATE_PS_PARAMS_MISC.
The behaviour is unchanged, except one minor change:
D3DRS_FOGTABLEMODE doesn't need to affect VS.
Signed-off-by: Axel Davy <davyaxel0@gmail.com>
With some test app I hit the limit.
As we allocate on demand (up to the maximum),
it is free to increase the limit.
Signed-off-by: Axel Davy <davyaxel0@gmail.com>
CC: <mesa-stable@lists.freedesktop.org>
Previously we had already found that for
MANAGED buffers the buffer started dirty
(which meant all writes out of bound
before the first draw call using the
buffer have to be taken into account).
Possibly it is the same for the other types of buffers.
For now always lock the entire buffer (starting from the offset)
for these (except for DYNAMIC buffers, which might hurt
performance too much).
Fixes: https://github.com/iXit/Mesa-3D/issues/301
Signed-off-by: Axel Davy <davyaxel0@gmail.com>
The previous code was ignoring the input
until a cursor is set inside d3d
(with SetCursorProperties), as expected
by wine tests.
However it did still make a call to ID3DPresent_SetCursor,
which would result into a SetCursor(NULL) call, thus
hidding any cursor set outside d3d, which we shouldn't do.
Add comment about not avoiding redundant ID3DPresent_SetCursor
calls once a cursor has been set in d3d, as it has been tested to
cause regressions.
Fixes: https://github.com/iXit/Mesa-3D/issues/197
Signed-off-by: Axel Davy <davyaxel0@gmail.com>
For some applications SetCursorPosition
is called when a cursor event is received.
Our SetCursorPosition was always calling
wine SetCursorPos which would trigger
a cursor event.
The infinite loop is avoided by not calling
SetCursorPos when the position hasn't changed.
Found thanks to wine tests.
Fixes irresponsive GUI for some applications.
Fixes: https://github.com/iXit/Mesa-3D/issues/173
Signed-off-by: Axel Davy <davyaxel0@gmail.com>
CC: <mesa-stable@lists.freedesktop.org>
