Re: Cello/OS X update

From: Kenneth Tilton (ktilton_at_nyc.rr.com)
Date: 11/14/04

  • Next message: Paolo Amoroso: "Re: RAD, SK8, and a lisp development platform" 
    Date: Sun, 14 Nov 2004 19:39:33 GMT

    In article <87hdnsgt7i.fsf@Astalo.kon.iki.fi>,
     Kalle Olavi Niemitalo <kon@iki.fi> wrote:

    > Kenneth Tilton <ktilton@nyc.rr.com> writes:
    >
    > > Rahul's 9800 Pro runs at 380mhz and has 128mb ram because he was
    > > too cheap to spring for 256mb.
    >
    > I'm still using a Radeon 64 DDR that I once bought for >1000 FIM
    > (now 168 EUR).

    We better take up a collection for you. :) But of course, my point is
    that I do not think you run faster by yanking even the slowest GPU and
    making your CPU do the work via MesaGL.

    Rahul somehow thought that using Cello /requires/ one to do an insane
    amount of rendering. No, your app decides that. Cello just optimizes
    rendering, even if you are using MesaGL, by updating the bare minimum at
    each frame. Whatever GPU you have is just gravy.

    >
    > > So... yes, /OpenGL/ draws the whole screen with its own GPU.
    >
    > Does that work reasonably fast if using X11 over a network?
    > I presume it can be implemented efficiently, if OpenGL already
    > makes a distinction between CPU and GPU data, but I don't know
    > how good the existing implementations are. IIRC, XFree86 had
    > trouble with this.

    I fear I know nothing of the issues. From first principles, I should
    think handling an update event on a remote display by transmitting
    nothing more than: "(gl-call-list 42)" would be efficient. I guess the
    problem is talking to the GPU while building lists? From first
    principles, it is hard to imagine anything more efficient than simply
    sending all the gl calls and their parameters over a pipe, especially
    when display lists and textures let you move stuff to the GPU once and
    then reuse to your heart's content.

    >
    > > Second, update regions are "dumb". Suppose I have several things masked
    > > in part by something which now disappears. Well, all the things masked,
    > > however little, must be re-rendered.
    >
    > That rendering can be very fast if you know the update region and
    > cache the rendered contents of containers,...

    Sounds like a plan.

    > like Borland's Turbo
    > Vision did in text modes. I hear such caching is now getting
    > fashionable again, for fancy transparency effects (which I guess
    > your display lists provide for free).

    Display lists are great, but in 3D and with lighting there is still the
    rest of the pipeline to be executed, such as bitwise occlusion and
    lighting application. So if you are just doing 2D and blitting bits into
    the graphics buffer you can go a lot faster. otoh, turn off lighting and
    do boring 2D graphics in OpenGL and you scream as well.

    Rahul is just a java monkey working for some bank, so he is unaware of
    things like games and especially MMORPGs, which have actually cut deeply
    into television viewing by males of certain age groups. That means there
    will be all the money in the world going into GPUs for years to come.

    I am a non-gamer myself, but my drinking buddies down at the pub are all
    addicted, and just playing with OpenGL and OpenAL enough to do my
    Amazing Spinning Shapes demo for Cello has me feeling like I just
    discovered programming and the hires graphics of the Apple II.

    OpenGL roolz, and Lisp is about to become the premier cross-platform
    OpenGL development platform. Yah, baby!!

    kt

  • Next message: Paolo Amoroso: "Re: RAD, SK8, and a lisp development platform"

    Relevant Pages

    • Re: OpenGL-based framebuffer concepts
      ... Someone once mentioned OpenGL ES as a possibility as it ... stack into the kernel including the rendering loops which tend to be ... GPU needs such advanced resource management that the X server (or ... delivery of GPU commands from userspace to hardware, ...
      (Linux-Kernel)
    • Re: OpenGL-based framebuffer concepts
      ... No GPU today "supports" OpenGL ... Kernel either passes the OpenGL commands to the GPU or if they ... I build an OpenGL rendering context. ...
      (Linux-Kernel)
    • Re: Why Lisp supposedly "sucks for game development"
      ... >> Could you tell me how you're using display lists this way? ... I'm very new to OpenGL. ... > rendering A and B within the room by simply calling their display lists, ... > ie, just as a scene is a tree of things, and things are a tree of parts, ...
      (comp.lang.lisp)
    • Re: Raytracing and modern Render Engines
      ... rendering, progressive rendering etc. ... that efficient exploit buffers and shading pipelines on the GPU. ... Here is a thesis that gives some idea of performance between 3 CPU ... and an NVidia GPU configuration: ...
      (comp.graphics.algorithms)
    • Re: Avid Liquid 7
      ... A combination of dual core/procs and GPU rendering should make many compositing tasks realtime and render expensive proprietary hardware unnecessary. ... Liquid has always had. ...
      (rec.video.production)