I have a small and simple 3d software rendering library to do in lisp
(as part of a university work) using cmucl + linux + X Window. It is
mostly transforming vertices, clipping triangles against a frustum and
filling triangles. The point is to implement these classic 3d
algorithm in lisp, if possible efficiently [it's part of the work to
determine if it it feasible reasonably fast in lisp].
So I need to access individual pixel of an X window the fastest
possible. I did some tests with CLX (that just encapsulate the Xlib)
using the image-z type (correspondind to XImage in term of Xlib)
and performance is not stellar as you imagine. The slowest part
is not the put-image to display the image (that acts as a buffer for
drawing) but clearing the image (just filling the buffer with 0's).
Software Mesa use XImages for software rendering.
I still haven't looked too much at Pixmap but I don't think it'll be
faster for accessing pixels.
I know clx is not maintained any more but what would be the difficulty
to extend it to support the DGA extension for example to allow direct
video access ? Is it just to send some new requests concerning DGA to
the server and reading replies (I don't know the X protocol very much)
?
If anyone know a faster way to access individual pixels than CLX,
please let me know...
If you know someone that knows well CLX please let me know too..
Michael Pujos.
--
Il fait bo!
Michael Pujos wrote:
> I have a small and simple 3d software rendering library to do in lisp
> (as part of a university work) using cmucl + linux + X Window. It is
> mostly transforming vertices, clipping triangles against a frustum and
> filling triangles. The point is to implement these classic 3d
> algorithm in lisp, if possible efficiently [it's part of the work to
> determine if it it feasible reasonably fast in lisp]
Correct cheat, not to the point: OpenGL is an X extension. The right way
is to make CLX OpenGL aware.
You have to see how GLX works, as well as checking out www.xig.com and
what's the XFree status regarding
this.
If you have to get to the point: mplement the equivalent of Mesa in Lisp.
Determining whether you can do reasonably fast 3D in Lisp using 2D X
primitives in the client make no sense.
--
Fernando D. Mato Mira
Real-Time SW Eng & Networking
Advanced Systems Engineering Division
CSEM
Jaquet-Droz 1 email: matomira AT acm DOT org
CH-2007 Neuchatel tel: +41 (32) 720-5157
Switzerland FAX: +41 (32) 720-5720
www.csem.ch www.vrai.com ligwww.epfl.ch/matomira.html
"Fernando D. Mato Mira" <········@iname.com> writes:
> Correct cheat, not to the point: OpenGL is an X extension. The right way
> is to make CLX OpenGL aware.
> You have to see how GLX works, as well as checking out www.xig.com and
> what's the XFree status regarding
> this.
IIRC, then Richard Mann has Open GL bindings for at least one
implementation of CL. Look at
http://www.neci.nj.nec.com/homepages/mann/software-available.html
Redoing what Open GL gives you (which means portability, lower
communication overhead and taking advantage of hardware support when
available) in Lisp (or C for that matter) seems like a huge waste of
time...
> If you have to get to the point: mplement the equivalent of Mesa in Lisp.
>
> Determining whether you can do reasonably fast 3D in Lisp using 2D X
> primitives in the client make no sense.
Exactly...
Regs, Pierre.
--
Pierre Mai <····@acm.org> PGP and GPG keys at your nearest Keyserver
"One smaller motivation which, in part, stems from altruism is Microsoft-
bashing." [Microsoft memo, see http://www.opensource.org/halloween1.html]
"Pierre R. Mai" wrote:
> IIRC, then Richard Mann has Open GL bindings for at least one
> implementation of CL. Look at
Yup. But I thought that kind of broke the rules by bypassing CLX.
And if Lisp can be as efficient as C, you'd win by saving 1 function call if
you do the marshalling directly in Lisp.
--
Fernando D. Mato Mira
Real-Time SW Eng & Networking
Advanced Systems Engineering Division
CSEM
Jaquet-Droz 1 email: matomira AT acm DOT org
CH-2007 Neuchatel tel: +41 (32) 720-5157
Switzerland FAX: +41 (32) 720-5720
www.csem.ch www.vrai.com ligwww.epfl.ch/matomira.html
"Fernando D. Mato Mira" wrote:
> Correct cheat, not to the point: OpenGL is an X extension. The right way
> is to make CLX OpenGL aware.
> You have to see how GLX works, as well as checking out www.xig.com and
> what's the XFree status regarding
> this.
XFree 4.0 has been released yesterday. It integrates GLX and DRI.
--
Fernando D. Mato Mira
Real-Time SW Eng & Networking
Advanced Systems Engineering Division
CSEM
Jaquet-Droz 1 email: matomira AT acm DOT org
CH-2007 Neuchatel tel: +41 (32) 720-5157
Switzerland FAX: +41 (32) 720-5720
www.csem.ch www.vrai.com ligwww.epfl.ch/matomira.html
······@mail.dotcom.fr (Michael Pujos) writes:
> I have a small and simple 3d software rendering library to do in lisp
> (as part of a university work) using cmucl + linux + X Window. It is
> mostly transforming vertices, clipping triangles against a frustum and
> filling triangles. The point is to implement these classic 3d
> algorithm in lisp, if possible efficiently [it's part of the work to
> determine if it it feasible reasonably fast in lisp].
If you were doing this for some real purpose, you'd be better off
relying on ready-made libraries -- at the very least you could let the X
server (ie, ultimately the blitter of the graphics card) draw the
clipped triangles. Note that people who make fast software renderers
(not that it's very common in this day and age of fast graphics
hardware) code their innermost loops in assembly because even C won't
give optimal performance. However, within the bounds of your assignment
it should be quite possible to reach performance within a smallish
constant factor of C. Unfortunately the bottleneck in a software
renderer will be in the updating of framebuffer bits, and
super-efficient bit twiddling isn't the area lisp excels in.
> So I need to access individual pixel of an X window the fastest
> possible. I did some tests with CLX (that just encapsulate the Xlib)
> using the image-z type (correspondind to XImage in term of Xlib)
> and performance is not stellar as you imagine. The slowest part
> is not the put-image to display the image (that acts as a buffer for
> drawing) but clearing the image (just filling the buffer with 0's).
> Software Mesa use XImages for software rendering.
> I still haven't looked too much at Pixmap but I don't think it'll be
> faster for accessing pixels.
I believe the problem is that your image buffer access code is
suboptimal. I don't know how to make CMUCL generate anywhere near
optimal memory clearing code -- having looked at the assembly CMUCL
generates from type-declared code with maximum speed optimizations, it
seems that CMUCL cannot convert array traversals into pointer
arithmetic. I'd look at using some foreign C code, or using inline
assembly; as another option, it may well be that somewhere in CMUCL
there already is a routine analogous to C memset().
Since you want to do software rendering, using Pixmaps (which are stored
in the X server) does not make sense.
> I know clx is not maintained any more but what would be the difficulty
> to extend it to support the DGA extension for example to allow direct
> video access ? Is it just to send some new requests concerning DGA to
> the server and reading replies (I don't know the X protocol very much)
> ?
I don't think you'll win that much by using DGA, although it would make
sense to get access to at least the MIT shared memory extension to avoid
transferring the pixmap over a socket. I doubt CLX has any support for
the SHM extension either; the problem would be fitting the shared memory
area in the lisp memory image. However this is just a guess, based on
having seen many discussions of problems with the subtleties of CMUCL
memory range allocation.
> If anyone know a faster way to access individual pixels than CLX,
> please let me know...
As noted, I don't think the problem is CLX but suboptimal updating of
the image buffer. I don't know how experienced you are in tweaking
CMUCL optimizations, but how about posting your image clearing or
triangle filler code so we can see if it could be improved?
Hannu Rummukainen
--
Disclaimer: I do not know what I am talking about.
Michael Pujos wrote:
>
> I still haven't looked too much at Pixmap but I don't think it'll be
> faster for accessing pixels.
> I know clx is not maintained any more but what would be the difficulty
> to extend it to support the DGA extension for example to allow direct
> video access ? Is it just to send some new requests concerning DGA to
> the server and reading replies (I don't know the X protocol very much)
> ?
> If anyone know a faster way to access individual pixels than CLX,
> please let me know...
DGA probably won't help. Pixel writing takes time, unless you have
double buffering in hardware, because the video hardware controller will
most often be set to write to the graphics memory during
vertical/horizontal retrace only.
There are scanline techniques if you're really set to have fast display
updates, but they require some special data structures that could be
awkward in CL. You can study the technique in e.g. ACM 4.8, a flight
simulator for X11 (and MS Windows too).
Or you could check if MPEX (an X extension) supports _efficient_ double
buffering nowadays. But I agree with the other responders - fast
graphics must be done almost at the video controller level, so Open GL
is a better choice. But then your university work would be halfway
solved, although not in CL.
Lars Lundback