ATI R600g Gains Mip-Map, Face Culling Support

[rohcQaH]

Problems I've identified:

- on the two BEVEL gears, the author didn't quite know which values to use, leading to inconsistent radii on different parts of the gear. Result: broken geometry

- on the outer teeth-polygons of the BEVEL gears, the faces are flipped: the visible faces are the BACK faces. The normals still point outwards of the gear, which cannot give good results.

- it's using a GL_QUAD_STRIP, but on BEVEL gears the quads aren't planar. Is there even a "right" way to shade non-planar QUADs?

- the normal vectors are calculated in a way that's valid for the next QUAD submitted inside the GL_QUAD_STRIP, which would be perfect for glShadeModel(GL_FLAT). But since glShadeModel() is never called, the default GL_SMOOTH is used. The result is visible on all gears if you look close enough.


So.. it's a test-case. Fixing everything may make it beautiful, but not necessarily more useful as a test-case. Does this program have a certain purpose to test specific features that must continue to be used?

[nanonyme]

So.. it's a test-case. Fixing everything may make it beautiful, but not necessarily more useful as a test-case. Does this program have a certain purpose to test specific features that must continue to be used?

I guess this all comes down to one question: does OpenGL define behaviour under the circumstances you said?

[rohcQaH]

Not sure about the non-planar quads, but to my knowledge everything else is defined and valid - it's just that the "correct" rendering looks like an error.

I'll post to mesa-dev tomorrow.

[marek]

On the other hand, having a test which uses the API in somewhat incorrect way is not bad either.

[nanonyme]

On the other hand, having a test which uses the API in somewhat incorrect way is not bad either.

Assuming the correct behaviour is to fail the test, sure.

[Mickabouille]

Assuming the correct behaviour is to fail the test, sure.

Hm, let's say "pass the test by failing"

[tball]

I might open a new thread, but I came to think of the following:
In my vdpau backend, I am using some bits from the mplayer implementation to my bitstream parser. Well i know mplayer is GPL'ed and my code will be too, but do I have to copy any kind of license from the GPL'ed source file from mplayer into my code?

[nanonyme]

I'm not a lawyer but I'd suspect loaning ideas from there is a just fine without any license concerns but loaning code not. Then again, whether or not these two things are equal is the bit where you decide on whether you want to take a guess which has its risks or hire an engineer with legal experience to sort the problem out for you.

[tball]

I'm not a lawyer but I'd suspect loaning ideas from there is a just fine without any license concerns but loaning code not. Then again, whether or not these two things are equal is the bit where you decide on whether you want to take a guess which has its risks or hire an engineer with legal experience to sort the problem out for you.

Well lets just say that I am using some of their bit parsing. I thought it would be easier just using their code, instead of me having to re-invent the wheel. It is basically only code such as:

bitstream_parameter = bitstream[0] << shift

etc.

[marek]

An incorrect test which is supposed to fail but doesn't crash a GPU or Mesa means that Mesa/GPU passes and handles the incorrectness correctly. :P

Concerning the licensing issues, you can't copy a GPL code and commit it in Mesa.