Write your own Einstein@home screensaver

Oliver Behnke
Oliver Behnke
Moderator
Administrator
Joined: 4 Sep 07
Posts: 942
Credit: 25166626
RAC: 0

Beautiful indeed!

Message 78321 in response to message 78320

Beautiful indeed!

 

Einstein@Home Project

Mike Hewson
Mike Hewson
Moderator
Joined: 1 Dec 05
Posts: 6534
Credit: 284730859
RAC: 105773

OK : after a ton of testing,

OK : after a ton of testing, trial and error, getting absolutely every rake hidden in the uncut lawn grass to hit my face, but including acquiring some really cool GL and GLSL tools, also while paying my son in apple cider to debug & flog it, I have written a pretty neat ( says he ... ) user friendly abstraction layer above all the shader crap. Here is 'first light' on that as an integrated executable :

.... woo woo woo & what a lovely triangle we have ! By the by I have also ditched the ES for good. It is just too cut-down for my liking. Specifically ES 2.0 doesn't have Vertex Array Objects ( VAO's ) and so having to continually reconstruct the graphics pipeline's input end ( how you shovel the data in ) for each and every frame is way too clumsy. The above is an Open GL 3.2 CORE effort using GLSL 1.5, on the existing base of GLEW, BOINC Graphics API subset, SDL & SDL_TTF, Freetype 2 and LibXML.

There is a spider's web of sequence dependencies in the 'modern' GL state machine. It will blow up quick slick if the wrong functions are called when the current state is just not quite right. This is especially relevant to the state of the rendering pipeline in detail. You know, the bit that prior GL versions gave you blissful ignorance of. I have hopefully successfully buried that ordering inside the C++ classes. That's what they are for ! :-)

One annoying error to debug has finally today been marked with the enumerant MIKE_IS_A_DUFUS, that being : expecting a pointer to a local/stack array to persist on function exit. You still have the pointer of course, it's an address, it doesn't seg-fault at all, but the data becomes crud. Right. Good one Mike. That's straight from Code Boners 101*. You just don't get that time back do you ? :-)

Cheers, Mike.

* Having said that I believe such venom bites do have an immunising effect though, by virtue of persistent memory of the pain from realising that the effort/time wasted was all your own work. :-)

I have made this letter longer than usual because I lack the time to make it shorter ...

... and my other CPU is a Ryzen 5950X :-) Blaise Pascal

Mike Hewson
Mike Hewson
Moderator
Joined: 1 Dec 05
Posts: 6534
Credit: 284730859
RAC: 105773

FWIW here is my strong

FWIW here is my strong recommendation for a GL/GLSL debugger/trace program called Apitrace :

... this screenshot is of that triangle code in action. To be exact one winds up running the chosen executable under Apitrace ( as a child process ) and Apitrace sniffs endlessly at the GL state machine ie. by tracing the API calls from your client program. A 'trace file' is produced per client program invocation, which one then inspects at leisure with the GUI above. There is a pure command line version.

It's for Linux and more. It is preferred that one builds from source ( Cmake & Make after gitting the source from GitHub ). To build the GUI version one needs Qt4 libs. It tells you all the calls, errors on the calls, frame by frame ( end of frame is defined as when the buffers swap ), full state info, shader internals, buffer contents .... etc. A tremendous tool and it's free ! :-)

Cheers, Mike.

( edit ) There is one called GLSL-Debugger ( previously known as glslDevil ) but has no documentation evident for it ! The 'Online Help' bounces you to a 404 ....

I have made this letter longer than usual because I lack the time to make it shorter ...

... and my other CPU is a Ryzen 5950X :-) Blaise Pascal

Bill592
Bill592
Joined: 25 Feb 05
Posts: 786
Credit: 70825065
RAC: 0

RE: .... woo woo woo &

Message 78324 in response to message 78322

Quote:

.... woo woo woo & what a lovely triangle we have !

Mike, what if Pink Floyd complains about you borrowing
their album cover design from "The Dark Side of the Moon ? "
JKJK )

Bill

Mike Hewson
Mike Hewson
Moderator
Joined: 1 Dec 05
Posts: 6534
Credit: 284730859
RAC: 105773

Check this out Bill, to break

Check this out Bill, to break Pink Floyd copyright I have this build system for the screensaver :

Two screens are coming from each of two NVidia 7-series cards, those being of the black case with the blue lights lurking behind the right-most screen ( all are BENQ's that I have 'accumulated' over the last five years ). That's a linux system on an Intel x86_64 type processor ( Corsair H100 liquid cooling ) with 32GB of RAM, a ton of terabytes on disk, using a Fedora 21 'spin' with an Xfce desktop. I found I just couldn't get the monitors right with Gnome or KDE, with Xfce there is a single GUI tool called 'Arandr' that one arranges the physical relations of the monitors with. Effectively it's a single X-screen spanned by all the monitors, Arandr writes the config file for X11 to use. Xfce also has 4 workspaces by default which you just click on the taskbar to switch between. At present the drivers I use for development are pure Mesa. I have two other systems further to the right on the shelf, not shown, those being a Windows 7 Ultimate and a much older XP box. I have an Aten CVI Dual Link KVMP 4-port switch to cycle their output to the lower middle monitor.

Here are the system specs. Of course all this is 'required' for the project, right? :-) :-)

Cheers, Mike.

( edit ) I forgot to mention my retro 'Tron' keyboard ... the keypad currently on the right can be moved to the left if you like, there's a hidden double female USB adapter that you use.

I have made this letter longer than usual because I lack the time to make it shorter ...

... and my other CPU is a Ryzen 5950X :-) Blaise Pascal

Bill592
Bill592
Joined: 25 Feb 05
Posts: 786
Credit: 70825065
RAC: 0

RE: Check this out Bill, to

Message 78326 in response to message 78325

Quote:

Check this out Bill, to break Pink Floyd copyright I have this build system for the screensaver :

Howdy Mike !
That is a Great Workstation you have assembled !

Bill

Mike Hewson
Mike Hewson
Moderator
Joined: 1 Dec 05
Posts: 6534
Credit: 284730859
RAC: 105773

RE: At present the drivers

Quote:
At present the drivers I use for development are pure Mesa.


Late Addendum : the reason I have not used the proprietary NVidia drivers is that you're locked to their configuration tool ( 'nvidia-config' ) which totally screws the setup of my particular choice of hardware. Even if I use nvidia-config as root/su.

I might throw together a minimal Linux 32 bit system for testing what's produced on the 64 bit one. Now let me sort through my retired parts array .....

Cheers, Mike.

I have made this letter longer than usual because I lack the time to make it shorter ...

... and my other CPU is a Ryzen 5950X :-) Blaise Pascal

Mike Hewson
Mike Hewson
Moderator
Joined: 1 Dec 05
Posts: 6534
Credit: 284730859
RAC: 105773

Now here's nice surprise ie.

Now here's nice surprise ie. GLM has provided the matrix transforms which mimic those previously provided by GLU :

Quote:

[pre]5.2. GLM replacements for GLU functions

From GLM_GTC_matrix_transform extension:

gluLookAt:

glm::mat4 glm::lookAt(glm::vec3 const & eye,
glm::vec3 const & center,
glm::vec3 const & up);

glm::dmat4 glm::lookAt(glm::dvec3 const & eye,
glm::dvec3 const & center,
glm::dvec3 const & up);

gluOrtho2D:

glm::mat4 glm::ortho(float left, float right, float bottom, float top);

glm::dmat4 glm::ortho(double left, double right, double bottom, double top);

gluPerspective:

glm::mat4 perspective(float fovy, float aspect, float zNear, float zFar);

glm::dmat4 perspective(double fovy, double aspect, double zNear, double zFar);

gluPickMatrix:

glm::mat4 pickMatrix(glm::vec2 const & center,
glm::vec2 const & delta,
glm::ivec4 const & viewport);

glm::dmat4 pickMatrix(glm::dvec2 const & center,
glm::dvec2 const & delta,
glm::ivec4 const & viewport);

gluProject:

glm::vec3 project(glm::vec3 const & obj,
glm::mat4 const & model,
glm::mat4 const & proj,
glm::{i, ' '}vec4 const & viewport);

glm::dvec3 project(glm::dvec3 const & obj,
glm::dmat4 const & model,
glm::dmat4 const & proj,
glm::{i, ' ', d}vec4 const & viewport);

gluUnProject:

glm::vec3 unProject(glm::vec3 const & win,
glm::mat4 const & model,
glm::mat4 const & proj,
glm::{i, ' '}vec4 const & viewport);

glm::dvec3 unProject(glm::dvec3 const & win,
glm::dmat4 const & model,
glm::dmat4 const & proj,
glm::{i, ' ', d}vec4 const & viewport);[/pre]

... the return values of these functions which would hence be available to provide as program uniform variables and so into the shader code.

Cheers, Mike.

I have made this letter longer than usual because I lack the time to make it shorter ...

... and my other CPU is a Ryzen 5950X :-) Blaise Pascal

Oliver Behnke
Oliver Behnke
Moderator
Administrator
Joined: 4 Sep 07
Posts: 942
Credit: 25166626
RAC: 0

That's indeed good to know.

Message 78329 in response to message 78328

That's indeed good to know. Now how about adding quadrics...?

 

Einstein@Home Project

Mike Hewson
Mike Hewson
Moderator
Joined: 1 Dec 05
Posts: 6534
Credit: 284730859
RAC: 105773

RE: That's indeed good to

Message 78330 in response to message 78329

Quote:
That's indeed good to know. Now how about adding quadrics...?


GLM doesn't have that. But I have a Sphere class which generates a vertex listing that yields a geodesic type frame composed of triangles.

I have considered generalising ( because I can !? ) to cylinder and disc, though a disc is really a very short cylinder. A torus/donut would be useful too.

Algorithmically they are much the same, having :

- circularity ie. the end meets the start, along at least one coordinate progression.

- need for normals to light.

- color at the vertex ( perhaps implying extension to the triangle faces )

- need for texture co-ordinates for pasting images on.

.... however they differ with respect to the particular generator of the vertex co-ordinates.

A general quadric then has/needs parameters for :

- overall dimensions eg. a sphere's radius

- granularity of modelling eg. how many slices/partitions along the relevant axes

- what totality of information is desired per vertex eg. position, normals, color, texture co-ords.

- possibly some prescription of base representation eg. float, double etc.

One important issue I have discovered : if you scale the object then DON'T scale the normals ! Keep them unitary.

The 'output' of a quadric format would be a 1D array of records, possibly with another array of indices into that one. Each record is the same structure of vertex attributes. This could be wrapped up into high level calls that invoke generation and rendering. Naturally one would have a 'Quadric' base class, virtual for that matter, plonking the shape specifics into subclasses to solidify the virtual stuff. I guess that is the idea ....

Consider it on my to-do-list ! :-)

Cheers, Mike.

( edit ) As discussed elsewhere, you have to use triangles in the modelling. Quadrilaterals are out in later OpenGL ...

( edit ) Mind you, one can 'fake it' eg. have coplanar triangles ( or possibly a sequence of lines ) but the API doesn't natively support quads. However the fixed parts of the rendering engine may catch you out by producing artifacts if you don't get it truly right though. This then gets down to low level stuff like number representation formats ie. when are two floating points equal, and when do you have the right to expect equivalent mathematical expressions ( notably commuting transforms ) to yield that ?

I'm sure you're familiar with all of that. FWIW GLSL has an 'invariant' qualifier that may be used to ( allegedly ) force equivalence of computation outcomes across programs ( on a given machine ). There's a time cost in that because it requires some degree of introspection and adjustment at runtime. Very clever feature, but IIRC it's a bit like 'inline' ie. at most a hint and might indeed be ignored by the implementation. For graphics production this is probably neither here nor there. I think it was included for regularity of compute shader outcomes, when doing 'multi-pass' techniques especially.

( edit ) One may wonder why I use a 32GB RAM machine. Firstly because I can [ :-) ], but it turns out that 'unrolling' much of the C++ standard library template classes can massively blow out the compiler's memory needs, at least for short periods on g++.

I have made this letter longer than usual because I lack the time to make it shorter ...

... and my other CPU is a Ryzen 5950X :-) Blaise Pascal

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.