On 2002.04.10 19:40 José Fonseca wrote:
... since the specs give some tolerance it would be nice to run the
conformance tests with different settings in mmx_blend.S, specially the
single multiply w/o rouding ...
I've started to play with glean and I tried to check this myself, but it
José Fonseca wrote:
On 2002.04.10 19:40 José Fonseca wrote:
... since the specs give some tolerance it would be nice to run the
conformance tests with different settings in mmx_blend.S, specially the
single multiply w/o rouding ...
I've started to play with glean and I tried to
On 2002.04.12 14:43 José Fonseca wrote:
On 2002.04.10 19:40 José Fonseca wrote:
... since the specs give some tolerance it would be nice to run the
conformance tests with different settings in mmx_blend.S, specially the
single multiply w/o rouding ...
I've started to play with glean
On Fri, Apr 12, 2002 at 08:33:17AM -0600, Brian Paul wrote:
Yes, just blendFunc is sufficient. I usually run glean like this:
glean -r res --visuals id==35 -t blendFunc
Where '35' is a typial GLX visual. Otherwise all the visuals are tested -
which is overkill if you're focused on
On Fri, Apr 12, 2002 at 02:43:00PM +0100, José Fonseca wrote:
|
| I've started to play with glean and I tried to check this myself, but it
| seems there is no effect in the results no matter what changes I make in
| mmx_blend.S. ...
The blend test only fails if an error is greater than one
On Fri, Apr 12, 2002 at 05:12:33PM +0100, Michael wrote:
|
| iirc, there's a bug in tblend.cpp, when it does the
| check, it doesn't increment ePix, aPix so some pixels aren't checked.
Yep, that's definitely a bug. Why haven't I heard a bug report before
now? :-)
Fix is checked in.
Allen
On 2002.04.12 18:26 Allen Akin wrote:
On Fri, Apr 12, 2002 at 02:43:00PM +0100, José Fonseca wrote:
|
| I've started to play with glean and I tried to check this myself, but
it
| seems there is no effect in the results no matter what changes I make
in
| mmx_blend.S. ...
The blend test
On Fri, Apr 12, 2002 at 07:01:08PM +0100, José Fonseca wrote:
| ... Although doing (p*a+q*(1-a)) 8 can
| introduce up to 1 LSB error and worst, it doesn't obey to the rule of
| 255*255 = 255 as 255*255/256 = 254. I know that in Mesa's C blending code
| this special
Allen Akin wrote:
On Fri, Apr 12, 2002 at 07:01:08PM +0100, José Fonseca wrote:
| ... Although doing (p*a+q*(1-a)) 8 can
| introduce up to 1 LSB error and worst, it doesn't obey to the rule of
| 255*255 = 255 as 255*255/256 = 254. I know that in Mesa's C blending
Allen Akin wrote:
If the expected value is 255 and the OpenGL implementation yields 254,
that's only one LSB of error, so glean probably won't complain about it.
We could make the test more stringent, but then some reasonable
implementations (especially some hardware implementations)
On Fri, Apr 12, 2002 at 01:14:30PM -0600, Brian Paul wrote:
|
| One might expect that the following identities be true for blending terms:
|
| 1.0 * 1.0 == 1.0
| 1.0 * x == x * 1.0 == x
| 0.0 * x == x * 0.0 == 0.0
|
| So for 8-bit channels, in fixed point:
|
| 255 *
On 2002.04.10 17:42 Brian Paul wrote:
José,
I've checked in the code after testing with Glean and the OpenGL
conformance
tests.
Great.
Was I supposed to change something in the C code? It passes the
conformance tests as-is.
I was surprised that the C code passed the conformance
12 matches
Mail list logo
