Moving it to dri-devel, since this is really a development issue, not a
user question.
Am Montag, den 20.03.2006, 13:27 +0800 schrieb alex. gouaillard:
Are you testing with the same hardware and the same 3D (Mesa) driver on
all OSes?
yep, same hardware, OpenSolaris, FC4, freeBSD. Apparently the kernel
would "delay" the SIGSTP untill the rendering is done. I did not get all
the details, but for sure, with the same code, it is working just fine
under FC4.
Note that there is also some chance involved. glxgears isn't holding the
lock all the time.
true again, that's why I could not reproduce it in the first place. I
wrote another OpenGl program, more complex, that is reaching the limits
of the HW, and then, I could almost always reproduce the afore
mentionned problem. The odd of its appearance when using quake2 was also
quite high.
I'm not aware of any fix or workaround for this problem. At least on
Linux it doesn't seem to occur in practice.
true. But afaik it has been addressed directly in linux, and not in DRI
framework's code, with leaves the problem open for other plateforms.
I still don't know what you're talking about. But I have a theory to
offer: I assume you're sending SIGSTOP by pushing Ctrl+Z in the terminal
emulator from where you started the GL application. That means there are
three processes involved in sending and delivering the signal: Xserver,
terminal emulator and GL application. The Xserver is holding the lock
when it receives the key-press from the hardware and sends a message
through a UDP socket to the terminal emulator. The terminal emulator
receives the key-press event from the Xserver and sends a signal to the
GL application. The exact outcome (whether the applications receives the
signal while holding the lock or not) depends a lot on implementation
details of process scheduling, inter-process communication and signal
delivery in the OS kernel. That's why you may see different behaviour on
different OSes.
You can take the Xserver of the equation (just for the sake of testing
the theory) by sending the signal from an ssh session. You'd still have
two processes involved though: the one sending the signal and the one
receiving it. But there is no more potential synchronization with the
Xserver holding the lock short time before the signal is generated.
<I
agree, you have to be quite #%*^#%* to send a SIGSTP to your 3D client
in the first place>.
Or maybe signal delivery works differently on Solaris
and somehow has a better chance of delivering the signal while holding
the lock.
no, same process.
In theory. See my argument above. ;-)
I m thinking about implementing this solution:
instead of having the client:
- grab the lock (userland)
- render
- release the lock;
I would prefer wrap the three operations within an IOCTL that way the
client would:
- issue a system call
- kernel grab the lock
- rendering is done
- kernel release the lock
system call is sent back to the client.
that way, the client would not hold the lock accross system calls but
during system call, and would not be interrrupt by anything.
I'm not sure this is entirely feasible. The lock is also taken for
manipulating the SAREA, a data structure shared by all DRI clients. It
contains the lock, clipping rectangles, memory management information
and probably more I'm not thinking of right now. To get rid of the
client lock, you'd have to get rid of the SAREA as well and that would
be a big change in the very design of DRI.
Regards,
Felix
what do you guys think about that? Is it still in the "DRI-spirit" ?
alex.
P.S.: Why were you replying privately? No one supposed to know that Sun
is working on DRI drivers for Solaris? ;-) I'd prefer to keep the
dri-devel list in the loop. But it's up to you.
sorry, I though I replied to everyone :-)
It's absolutly NOT SECRET that sun is porting DRI to OpenSolaris. We
(kind of unofficially) announced it at everyone at the XDevConf. We are
planning to work closer to the opensource community, and DRI would be
only a start. We will release everything back to the openSource
community. Right now DRI framework has been entirely ported. Intel
chipset have been succesfully tested (i95 in the way because of agp
support in the kernel) and ATI radeon family is next.
