Live data from Hacker News

Purely Functional 3D in Typed Racket [video]

youtube.com

11–12 of 12 posts

Re: Purely Functional 3D in Typed Racket [video]

#11

The talk says it doesn't work on OS X because of which versions of OpenGL are supported. Neil, is that just because you don't know very well how to use the particular version OS X supports, or are there critical features of your Pict3D engine that won't work in OS X's version? (I like to do all my for-fun projects in OS X.)

More precisely, the problem comes from how certain Linux libraries and OS X have responded to OpenGL's new profile system.

An OpenGL context is roughly a 3D drawing area and its associated behind-the-scenes data. Via changes to OpenGL version 3.0 through 3.2, it became possible to ask for specific versions of OpenGL for each context. There are two kinds of contexts: "compatibility" contexts, which expose all OpenGL features up to the version obtained, and "core" contexts, which don't have deprecated features. For example, starting with 3.1, a core context won't draw quads - you have to split them into two triangles.

On Linux, Racket uses libgtkgl to get OpenGL contexts that are associated with GTK widgets. This library won't return anything but compatibility contexts, up to version 3.0.

On OS X, it's only possible to get an OpenGL 2.1 context or an OpenGL 3.2 or 3.3 core context.

There are a few ways to fix this.

1. The libgtkgl developers add support for core contexts and versions later than 3.0. I doubt this will happen. They're dragging their feet.

2. OS X adds support for compatibility contexts. Again, not hopeful.

3. We find some other way to get an OpenGL context on Linux that's associated with a GTK widget. There aren't many options.

4. I develop using OpenGL 2.1. I lose a lot of shading language features that way, though, and probably a lot of performance.

5. I develop multiple rendering paths. I hate this idea, but it may be what I have to do.

Re: Purely Functional 3D in Typed Racket [video]

#12
post #4

Earlier quoted context omitted.

It seems like the interesting thing is that it's a purely functional API. I don't thing they were trying to demonstrate that the language is fast.

Exactly. The engine is able to make excellent use of the GPU while sporting a purely functional API in Racket, a dialect of Lisp.

Right. I don't remember whether I said it in the talk, but that demo saturates the AGP bus, meaning that the engine can extract and write scene data at about 1.5 to 2 GB/Sec.

It's possible to put a lot more static content in each frame by uploading the vertex data to the card just once. That feature is on my to-do list.

Post reply on HN