0

for an application I'm developing I need to be able to

  • draw lines of different widths and colours
  • draw solid color filled triangles
  • draw textured (no alpha) quads

Very easy...but...

All coordinates are integer in pixel space and, very important: glReading all the pixels from the framebuffer on two different machines, with two different graphic cards, running two different OS (Linux and freebsd), must result in exactly the same sequence of bits (given an appropriate constant format conversion).

I think this is impossible to safely be achieved using opengl and hardware acceleration, since I bet different graphic cards (from different vendors) may implement different algorithms for rasterization. (OpenGl specs are clear about this, since they propose an algorithm but they also state that implementations may differ under certain circumstances). Also I don't really need hardware acceleration since I will be rendering very low speed and simple graphics.

Do you think I can achieve this by just disabling hardware acceleration? What happens in that case under linux, will I default on MESA software rasterizer? And in that case, can I be sure it will always work or I am missing something?

Nicol Bolas
  • 449,505
  • 63
  • 781
  • 982
O'Blivion
  • 21
  • 2
  • i think better approach will be to forget the exactness of rasterisation and the result handle as non exact (+/- few pixels) the overall rasterisation error is about 0.5 pixel (if i remember correctly) so for safety consider all objects with 2-3 pixels accuracy. (also you can add markers to critical objects... one pixel with distinct color). Another approach is to use GLSL (forget about OpenGL pipeline and create your own with predetermined accuracy behavior) – Spektre Sep 04 '13 at 09:51

1 Answers1

3

That you're reading back in rendered pixels and strongly depend on their mathematical exactness/reproducability sounds like a design flaw. What's the purpose of this action? If you, for example, need to extract some information from the image, why don't you try to extract this information from the abstract, vectorized information prior to rendering?

Anyhow, if you depend on external rendering code and there's no way to make your reading code more robust to small errors, you're signing up for lots of pain and maintenance work. Other people could break your code with every tiny patch, because that kind of pixel exactness to the bit-level is usually a non-issue when they're doing their unit tests etc. Let alone the infinite permutations of hard- and software layers that are possible, and all might have influence on the exact pixel bits.

If you only need those two operatios: lines (with different widths and colors) and quads (with/without texture), I recommend writing your own rendering/rasterizer code which operates on a 8 bit uint array representing the image pixels (R8G8B8). The operations you're proposing aren't too nasty, so if performance is unimportant, this might actually be the better way to go on the long run.

DerManu
  • 702
  • 4
  • 12
  • Thanks but it's not really a design flaw. It is required by a security application I'm writing. Too bad I can not enter in more details since it is NDA covered. But I can tell that hardware and software is not subject to changes after the release, so I understand your concerns about the maintenance work, but it's not an issue here. About the custom rasterizer...it is an option I'm evaluating but, you know, I'd like to write the less code I can.:-) – O'Blivion Apr 19 '12 at 18:33
  • Okay so since you have non-changing (and hopefully known) hardware and software, it's now not impossible but only hard. The problem is, that you have two different OSes and thus different compilers. In order to guarantee same results, you need at least deterministic floating point arithmetics (IEEE 754, http://stackoverflow.com/questions/328622/how-deterministic-is-floating-point-inaccuracy). This however, is typically only possible when using identical compilers (even a minor compiler version change can break this). My Suggestion: Experiment. If it works, don't change a thing, ever ;) – DerManu Apr 20 '12 at 02:06