Part of the Khronos Group
OpenGL.org

The Industry's Foundation for High Performance Graphics

from games to virtual reality, mobile phones to supercomputers

Page 2 of 3 FirstFirst 123 LastLast
Results 11 to 20 of 25

Thread: R520 - no FP texture filtering?

  1. #11
    Junior Member Regular Contributor
    Join Date
    Jun 2003
    Posts
    181

    Re: R520 - no FP texture filtering?

    Floating point filtering on the other hand is easily emulated in the shader.
    Which is fine for bilinear and to a certain extent trilinear. It's a whole other matter to (efficiently) do aniso.

  2. #12
    Member Regular Contributor
    Join Date
    Nov 2000
    Location
    Belmont, CA
    Posts
    254

    Re: R520 - no FP texture filtering?

    Something on-topic, and somethin off-topic:

    On topic: I second the bit about fragment branching. Soft shadows maps will probably benefit. Now your deferred shaders can dispatch on material efficiently. The possibilities are quite intriguing. The displayable HDR (and AA!) is also nice, but that'll eat up quite a bit of storage/bandwidth. I wonder what the performance of that will be like. And last I heard, render to vertex array was faster than render from vertex texture on NV hardware. But it's been a long time since I've tested that.

    Off topic: To be pedantic, the linear filter is a tent filter. The box filter is what they recommend for auto generating mipmap levels. But the point is clear: filters with narrow support universally suck.

    -W

  3. #13
    Senior Member OpenGL Guru
    Join Date
    Mar 2001
    Posts
    3,768

    Re: R520 - no FP texture filtering?

    FP16 multisampling, displable FP16 and RGB10_A2, RGB10_A2/R16/RG16/RGBA16/R16F render targets, fetch4, floating point HiZ, 3Dc+ (now with a single channel format as well), unlimited MRT support, angle invariant AF (well, they used to, but now they don't).
    Of these, the only one that is of significant importance is multisampling. I don't need to be able to display FP render targets directly, as I can just render to a texture and use that texture to convert the data to a displayable format. Plus, I get to take the opportunity to do other things (post-processing effects) with the texture while doing this, so in some cases, it isn't even a performance loss.

    Like the X1800 being over twice as fast as the 7800GTX in the dynamic branching heavy samples to be included in the next ATI SDK, and the X1600 competing very well with it.
    Yeah, like I'm going to believe a test that ATi designed. When an unbiased 3rd party comes up with such a scenario, then maybe we can talk.

  4. #14
    Senior Member OpenGL Guru Humus's Avatar
    Join Date
    Mar 2000
    Location
    Stockholm, Sweden
    Posts
    2,444

    Re: R520 - no FP texture filtering?

    Originally posted by gybe:
    What about Vertex Texturing? Are you at least going to support a render-to-vertex-array in OpenGL in a near future?
    Well that's on the ARB's table right now. I hope to see it added to FBOs at some point. We had superbuffers implemented in our drivers like two years ago or so. But things took another turn, things got moved to the ARB, which eventually mixed up with other stuff and we got FBOs, which doesn't support R2VB yet.

  5. #15
    Senior Member OpenGL Guru Humus's Avatar
    Join Date
    Mar 2000
    Location
    Stockholm, Sweden
    Posts
    2,444

    Re: R520 - no FP texture filtering?

    Originally posted by Won:
    The displayable HDR (and AA!) is also nice, but that'll eat up quite a bit of storage/bandwidth. I wonder what the performance of that will be like.
    It's quite good actually. In the new SDK that was released just today (http://www.ati.com/developer/radeonSDK.html) there's a new HDR sample that does AA. I saw a 14% performance hit by enabling 6xAA.

  6. #16
    Senior Member OpenGL Guru Humus's Avatar
    Join Date
    Mar 2000
    Location
    Stockholm, Sweden
    Posts
    2,444

    Re: R520 - no FP texture filtering?

    Originally posted by Korval:
    I don't need to be able to display FP render targets directly, as I can just render to a texture and use that texture to convert the data to a displayable format.
    Well, then you'll probably at least enjoy a RGB10_A2 backbuffer for better output precision. The displayable FP buffers may not be that useful to regular gamers. To truly take advantage of it you'll need one of those extremely expensive HDR displays. I haven't seen that in action myself, but supposedly it's pretty cool.

    Originally posted by Korval:
    Yeah, like I'm going to believe a test that ATi designed. When an unbiased 3rd party comes up with such a scenario, then maybe we can talk.
    Talk!

    http://www.xbitlabs.com/articles/vid...-x1000_21.html
    "In both these cases RADEON X1800 XT is undefeated. Moreover, in case of the hardest Heavy Dynamic Branching, it is twice as fast as the rival."

    http://www.xbitlabs.com/articles/vid...-x1000_27.html
    http://www.xbitlabs.com/articles/vid...-x1000_33.html

  7. #17
    Intern Contributor
    Join Date
    Mar 2004
    Location
    Victoria, Australia
    Posts
    79

    Re: R520 - no FP texture filtering?

    I had a look at those benchmarks Humus just posted.

    On the first page, i see the 7800 outperforming everything overall. Especially on benchmarks that are realistic for today's market. I would be very far from saying the ATI cards were unbeatable.

    However i do have to point out this quote "Xbitmark results prove this point once again: the overall performance of RADEON X1800 XT is lower or the same as that of GeForce 7800 GTX."

    But the last two pages dont mention the 7800, it only compares the ATI's newest and last generation (X1k and X#00) to nVidia's last generation (GF 6). Perhaps its becuase the rest of the GF 7's havent appeared yet. But still, new vs. old. Its like comparing the GF 6 series to the GF FX series.

    The second two i think are biased...it also doesnt mention what brand, an ASUS and a Sparkle would produce different results.

    Although, i think we are going off-topic...its turning into yet another ATI vs. nVidia thread.

    -Twixn-
    "These flowers were sent to harras me" - Jack Thompson

  8. #18
    Senior Member OpenGL Pro sqrt[-1]'s Avatar
    Join Date
    Jun 2002
    Location
    Australia
    Posts
    1,006

    Re: R520 - no FP texture filtering?

    Originally posted by Humus:
    Originally posted by Won:
    The displayable HDR (and AA!) is also nice, but that'll eat up quite a bit of storage/bandwidth. I wonder what the performance of that will be like.
    It's quite good actually. In the new SDK that was released just today (http://www.ati.com/developer/radeonSDK.html) there's a new HDR sample that does AA. I saw a 14% performance hit by enabling 6xAA.
    Wow! That SDK is getting so good I think it easily rivals Nvidia's now.

    Just how many examples and papers did you write in that Humus? Virtually all the examples smack of your "style".

  9. #19
    Advanced Member Frequent Contributor
    Join Date
    Nov 2002
    Location
    Latvia
    Posts
    628

    Re: R520 - no FP texture filtering?

    OK, new Radeons are as cool as GeForces now and have some decent features I miss on green team cards, but....

    WHEN THE HELL ATI WILL START TO THINK ABOUT UPDATING THEIR OPENGL DRIVER!?!?!?!?! Or are they in the Vista boat - Astalavista GL???

    Not thinking about getting any of their product till this is fixed!

  10. #20
    Senior Member OpenGL Guru Humus's Avatar
    Join Date
    Mar 2000
    Location
    Stockholm, Sweden
    Posts
    2,444

    Re: R520 - no FP texture filtering?

    Originally posted by sqrt[-1]:
    Wow! That SDK is getting so good I think it easily rivals Nvidia's now.

    Just how many examples and papers did you write in that Humus? Virtually all the examples smack of your "style".
    I did write the majority of the framework, so the samples adheres to that more or less. I wrote about 3 of 4 of those samples, but most of the duplicates between the API are mine, so maybe saying a bit over half is more fair. I wrote 3 of the new papers (HDR Texturing, Programming for CrossFire and Framebufer objects).

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •