[Mesa-dev] Why my account and all my MRs were removed from gitlab.freedesktop.org?

[andrey simiklit]

Hi all,

Today I faced a problem regarding my account @asimiklit on
gitlab.freedesktop.org, I can't sign in. It looks like user @asimiklit was
removed as well as my MRs. Something went wrong and I would like to sort
out the reason. Does somebody know something about this?


Additionally: My colleagues received messages like the following one:

> Merge request !6663
 was closed
by Daniel Stone

Regards,

Andrii.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] bad performance issue in GPU & CPU data sharing

[Zong, Wei]

Hello,



I'm using GLES shader to run algorithms on image frames, I got very bad 
performance issue in GPU & CPU data sharing, especially retrieve data from GPU 
to CPU.



Basically, I use glGenBuffers/glBindBuffer/glBufferData(target, size, data, 
usage) to create GPU buffer object and initialize GPU data store with CPU data 
pointer. After GLES shader finished the processing, I use glMapBufferRange to 
retrieve processed image data back to CPU, and for some reason I have to do an 
extra data copy from the gl map pointer to another CPU buffer, this is super 
slow.



Here's the code snippet 
https://github.com/intel/libxcam/blob/master/modules/gles/gl_buffer.cpp#L94

https://github.com/intel/libxcam/blob/master/modules/gles/gl_buffer.cpp#L127



I wonder If there has other efficient way to sharing data between CPU & GPU 
GLES shader?



Thanks,

Zong Wei

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] Linux Graphics Next: Userspace submission update

[Christian König]

Yes, exactly that's my thinking and also the reason why I'm pondering so 
hard on the requirement that the memory for shared user fences should 
not be modifiable by userspace directly.


Christian.

Am 29.05.21 um 05:33 schrieb Marek Olšák:

My first email can be ignored except for the sync files. Oh well.

I think I see what you mean, Christian. If we assume that an imported 
fence is always read only (the buffer with the sequence number is read 
only), only the process that created and exported the fence can signal 
it. If the fence is not signaled, the exporting process is guilty. The 
only thing the importing process must do when it's about to use the 
fence as a dependency is to notify the kernel about it. Thus, the 
kernel will always know the dependency graph. Then if the importing 
process times out, the kernel will blame any of the processes that 
passed it a fence that is still unsignaled. The kernel will blame the 
process that timed out only if all imported fences have been signaled. 
It seems pretty robust.


It's the same with implicit sync except that the buffer with the 
sequence number is writable. Any process that has an implicitly-sync'd 
buffer can set the sequence number to 0 or UINT64_MAX. 0 will cause a 
timeout for the next job, while UINT64_MAX might cause a timeout a 
little later. The timeout can be mitigated by the kernel because the 
kernel knows the greatest number that should be there, but it's not 
possible to know which process is guilty (all processes holding the 
buffer handle would be suspects).


Marek

On Fri, May 28, 2021 at 6:25 PM Marek Olšák > wrote:


If both implicit and explicit synchronization are handled the
same, then the kernel won't be able to identify the process that
caused an implicit sync deadlock. The process that is stuck
waiting for a fence can be innocent, and the kernel can't punish
it. Likewise, the GPU reset guery that reports which process is
guilty and innocent will only be able to report unknown. Is that OK?

Marek

On Fri, May 28, 2021 at 10:41 AM Christian König
mailto:ckoenig.leichtzumer...@gmail.com>> wrote:

Hi Marek,

well I don't think that implicit and explicit synchronization
needs to be mutual exclusive.

What we should do is to have the ability to transport an
synchronization object with each BO.

Implicit and explicit synchronization then basically become
the same, they just transport the synchronization object
differently.

The biggest problem are the sync_files for Android, since they
are really not easy to support at all. If Android wants to
support user queues we would probably have to do some changes
there.

Regards,
Christian.

Am 27.05.21 um 23:51 schrieb Marek Olšák:

Hi,

Since Christian believes that we can't deadlock the kernel
with some changes there, we just need to make everything nice
for userspace too. Instead of explaining how it will work, I
will explain the cases where future hardware (and its kernel
driver) will break existing userspace in order to protect
everybody from deadlocks. Anything that uses implicit sync
will be spared, so X and Wayland will be fine, assuming they
don't import/export fences. Those use cases that do
import/export fences might or might not work, depending on
how the fences are used.

One of the necessities is that all fences will become future
fences. The semantics of imported/exported fences will change
completely and will have new restrictions on the usage. The
restrictions are:


1) Android sync files will be impossible to support, so won't
be supported. (they don't allow future fences)


2) Implicit sync and explicit sync will be mutually exclusive
between process. A process can either use one or the other,
but not both. This is meant to prevent a deadlock condition
with future fences where any process can malevolently
deadlock execution of any other process, even execution of a
higher-privileged process. The kernel will impose the
following restrictions to protect against the deadlock:

a) a process with an implicitly-sync'd imported/exported
buffer can't import/export a fence from/to another process
b) a process with an imported/exported fence can't
import/export an implicitly-sync'd buffer from/to another process

Alternative: A higher-privileged process could enforce both
restrictions instead of the kernel to protect itself from the
deadlock, but this would be a can of worms for existing
userspace. It would be better if the kernel just broke unsafe
userspace on future hw, just like sync files.

If both implicit and explicit sync are