Daryll Strauss wrote:
> The locking system is designed to be highly efficient. It is based on a
> two tiered lock. Basically it works like this:
> The client wants the lock. The use the CAS (I was corrected that the
> instruction is compare and swap, I knew that was the functionality, but
> I got the name wrong) If the client was the last application to hold the
> lock, you're done you move on.
Excellent. So since our app will be the only X app running (we
hopefully won't need a window manager) then after initial window
creation and placement, we will always have the lock.
> If it wasn't the last one, then we use an IOCTL to the kernel to
> arbitrate the lock.
> In this case some or all of the state on the card may have
> changed. The shared memory carries a stamp number for the X server. When
> the X server does a window operation it increments the stamp. If the
> client sees that the stamp has changed, it uses a DRI X protocol request
> to get new window location and clip rects. This only happens on a window
> move. Assuming your clip rects/window position hasn't changed, the
> redisplay happens entirely in the client.
> The client may have other state to restore as well. In the case of
> the tdfx driver we have three more flags for command fifo invalid, 3D
> state invalid, textures invalid. If those are set the corresponding
> state is restored.
> So, if the X server wakes up to process input, it current grabs the lock
> but doesn't invalidate any state. I'm actually fixing this now so that
> it doesn't grab the lock for input processing.
Once that is complete, there will be no other reasons for the Xserver to
grab the lock, it appears. Cool.
> In the current implementation the X front buffer is the 3D front
> buffer. When we do page flipping we'll continue to do the same
> thing. Since you have an X window that covers the screen it is safe for
> us to use the X surface's memory. Then we'll do page flipping. The only
> issue will be falling back to blitting if the window is ever moved from
> covering the whole screen.
Excellent. Since we will never move the window, we should never have a
> > I guess I was unaware that X could run without an InputDevice being
> > defined. I guess I did not check the docs.
> I'm not sure it will, but it does seem like a reasonable thing to
> want. If that doesn't work, it could be added.
I'll look into it.. If it is not there, I'll attempt to add it.
> First, the kernel drivers are included in the stock 2.3.xx (soon to be
> 2.4) kernels. So hopefully users just get them by default.
> Second, whether or not users have to compile anything is a support
> issue. Kernel changes will require compiling by someone to keep them
> current with the kernel. As a distributor of a kernel module you can
> compile it for all the versions of Linux you support and/or you can
> provide source. Someone has to do the compile the question is whether
> you do it or they do and how much flexibility you want to leave them in
> their system configuration.
I am in agreement for 99% of the world. However, our systems are
turn-key. We use a particular system configuration and software
installation, we install all the software, and then ship it to the
customer. All our users know (and really care to know) is that they
have a rack of black PC's in the corner that draw the graphics. If they
get in and try to fart around with the configuration, we take their
warranty away... :)
Our operator's console software connects via a socket to the remote
rack, sends databases, runs the simulation, and retrieves collected
data. The users don't have to log into these machines at all. It is
all voodoo to them (Voodoo2, actually).
> So, the final solution is that distributions roll in XFree 4.0 and the
> 2.4 kernel and everything is hunky dorey. The user doesn't have to do
> anything to get 3D. As the drivers progress pieces can be individually
> updated. Even in the non-ideal world (where the distribution hasn't done
> everything) the installation should just be rpm -Uvh XFree(a few of
> them) GLU GLUT KernelDriver.
And, again, this is more important on our end, since we will be doing
the installations, and etc. But it will certainly be nice when a
distribution rolls everything in...
> Your solution means YOU have to package and maintain all those pieces
> you mentioned. They will not be rolled into the common base, because
> they are specific to your solution. My comment about packaging is that
> your packaging requirement goes up because you can't rely on the
> community to do more of the work for you. Also, your solution include
That is where I was hoping for a "following" of people for removing the
Xserver, for those who thought it was necessary. That way there would
be something official, instead of Mike Morrison doing it all himself
(which, in the end, he probably wouldn't if he was by himself :)
Regardless, it appears that it is a moot point, since you have convinced
me that it is not necessary anyway.
> "kernel driver" How do you avoid having them compile it? If you're
> willing to restrict the users choice of kernel/distribution/etc (which
> isn't unreasonable in some cases) then distributing a binary is easy in
> either case.
Once the machine ships, it is a HUGE deal to have to upgrade the kernel,
and we usually send a new hard drive, rather than allowing the potential
of a customer to mess up an upgrade. In the past 6 months, this has
only been required once. Again, we maintain everything here, and just
send the deltas that are required.
> > I am in total agreement here. With regards to this, is anyone working
> > on adding SSE support to the transform/lighting code in Mesa?
> SSE stuff was somewhat broken in the kernels until recently. In fact, we
> (Gareth Hughes to be precise) just submitted a big kernel patch that
> should fully support SSE. I don't know if anyone is working on them for
> Mesa, I haven't seen much in that area lately.
> I'd start with profiling your app against the current Mesa base, to
> decide where the optimization effort should go. I'm not convinced SSE is
> the next right step. There may be more fundamental optimizations to do
> first. We haven't spent a much time on optimizing it.
I guess I didn't mean to imply that SSE was the "next step". The guys
from Gemini (OpenGVS crew) said that it has provided one of the single
largest performance increases to-date in their SimGL driver (which rides
on top of Glide or D3D).
We have actually been working to add SSE support to SimGL under Linux.
However, since GCC does not currently support the intel "SSE Intrinsics"
(which GVS used), nor does it seem to properly support __attribute__
((aligned)) for our typedef of __m128, we decided to proceed down the
path of NASM and assembly, where possible. We may end up bailing on
this anyway, since other solutions have presented themselves.
Michael M. Morrison
VP/Chief Technical Officer
Hyperion Technologies, Inc.