1) GPU 1 writes to CPU RAM, GPU 2 reads from CPU RAM

2) GPU 1 writes to GPU 2 RAM via PCI Express (DMA between devices)

3) GPU 2 reads from GPU 1 RAM via PCI Express (DMA between devices)

Actually I think the opposite will usually hold: you will still have a green wave if you drive at the expected speed divided by an integer.

What you can do is:

- determine if a float is an integer (trunc(x) == x),

- convert a float to a certain integer type with some kind of rounding, or get an error if it's out of range (see my comment with double_to_uint64),

- convert a float to a certain integer type exactly, or get an error if it's not representable (e.g. by doing both of the above).

The basic reason that so many people fail to use floats correctly is that they act like operations on floats are equivalent to operations on the real numbers they represent, when in fact they are usually defined as the operation on real numbers rounded to a representable value.

Be aware that +0.0 and -0.0 are different floating point values but represent the same real number, so +0.0 == -0.0 follows.

People who say == means nothing for floating point and you always need epsilon checks are wrong, plain and simple. == is very well defined. Don't confuse the definition of floating point operations with common practices for using them effectively.

You can iterate through all non-NaN values and check that successive ones are indeed not equal:

    #include 
    #include 
    #include 
    #include 
    #include 

    int main()
    {
        float x = (float)-INFINITY;
        uint64_t count = 1;
        while (x != (float)INFINITY) {
            float y = nextafterf(x, (float)INFINITY);
            assert(y != x);
            x = y;
            ++count;
        }
        printf("Found %" PRIu64 " floats.\n", count);
        return 0;
    }
    
    $ gcc -std=c99 -O3 a.c -lm -o a
    $ ./a
    Found 4278190081 floats.

Interestingly, this only finds one zero (-0.0), hence the assert doesn't actually fail around zero.

"When a value of integer type is converted to a real floating type, if the value being converted can be represented exactly in the new type, it is unchanged. If the value being converted is in the range of values that can be represented but cannot be represented exactly, the result is either the nearest higher or nearest lower representable value, chosen in an implementation-defined manner. If the value being converted is outside the range of values that can be represented, the behavior is undefined."

See it says implementation-defined manner, not according to the current rounding mode.

Test case:

    #pragma STDC FENV_ACCESS ON
    #include 
    #include 
    #include 

    int main()
    {
        fesetround(FE_DOWNWARD);
        printf("%f\n", (double)UINT64_MAX);
        fesetround(FE_UPWARD);
        printf("%f\n", (double)UINT64_MAX);
        return 0;
    }

    $ gcc -std=c99 -frounding-math x.c -lm
    $ ./a.out 
    18446744073709551616.000000
    18446744073709551616.000000

    bool double_to_uint64 (double x, uint64_t *out)
    {
        double y = trunc(x);
        if (y >= 0.0 && y < ldexp(1.0, 64)) {
            *out = y;
            return true;
        } else {
            return false;
        }
    }

Explanation:

- we first round the value to an integer (but still a floating point value),

- we then check that this integer is in the valid range of the target integer type by comparing it with exact integer values (0 and 2^N),

- if the check passes, then converting this integer to the target integer type is safe, and if the check fails, then conversion is not possible.

Of course if you literally need to convert to "long" you have a problem because the width of "long" is not known, but that is a rather different concern. I argue types with unknown width like "long" should almost never be used anyway.

(based on my answer here: https://stackoverflow.com/questions/8905246/how-to-check-if-...)

- gfx.webrender.all = true (important on Linux, fixes jerky scrolling)

- general.smoothScroll.mouseWheel.durationMaxMS = 200 (makes mouse scroll animation faster)

That sounds like a bug to me which should be reported.