View Full Version : ARB2 and FP in OpenGL ?
05-15-2003, 01:00 AM
I am looking for several hours now and i can't find any docs on ARB2 extensions. I bought a new graphics card (r300) and would like to do some floating point fragment stuff in opengl without getting vendor-specific.
Where can i find any information on Floating Point formats in OpenGL and information on ARB2 fragment programs (if there is a ARB2 vertex program implementation with flowcontrol i would also love it).
I hope there is a way and i will not have to wait until GL2 arrives.
05-15-2003, 01:36 AM
Start with ARB_vertex_program, ARB_fragment_program here http://oss.sgi.com/projects/ogl-sample/registry/
05-15-2003, 02:07 AM
Thanks, but i know the ARB_fragment_program. It sucks on mantissa and exponent. I know this kind of shaders very well from dx 8.1, but i do not like them. I would love some kind of flowcontrol for the vertex shaders and at least my 64bit of precision on fragment level.
Is there really nothing to do ?
How does Doom3 use OpenGL 1.x to adress Floating Point stuff on ARB Level (I can choose the R200 or !ARB2! Path on my R9700).
I hope there is a way, because else i will have to turn away from OpenGL and get back to DX9. OpenGL makes more fun to code with and i got very used to it in the last 4 years.
Please help me, i don't have the time and the money (for hardware) to make Vendor-Specific implemantations.
Is there NO way ?
05-15-2003, 02:42 AM
No way, till GL2 arrives ?
05-15-2003, 03:13 AM
Buffers will be improved in the near future thanks to uberbuffers (the name may have changed) but you will have to wait a few months before the spec is out, and some other months before implementations are ready. That is for the ARB level.
If you're hurried, currently vendor-specific extensions is the best solution, even though you seem to hate / can't afford them.
05-15-2003, 03:31 AM
That's bad, because i can't stay with one GPU in mind.
So that seems to be the end of the long OpenGL Road for me. It was much easier to handle than D3D.
OpenGL is developing too slowly, to keep pace with D3D (Not Vendorspecific stuff, only ARB).
05-15-2003, 03:37 AM
The ATI extensions also seem to suck very bad. I missed a point or it is not possible to use a direct framebuffer with floatingpoints.
Did i miss something or do u really have to render off framebuffer and copy(switch) to a pbuffer ?
05-15-2003, 03:46 AM
I also looked at Doom3 once again and i am sure, that it does not use R300 Path for fragment programs and still uses the precision of ver2.0 fragment shaders. Of course i can't say anything to flowcontrol and so on, but it seems to be possible (with todays drivers) to use ARB-style fragment programs that can be executed on both the R300 and the NV30.
Is there any information on this subject ? Why should ATI and NVidia write Extensions for this if it's still not useable ?
I need some information on this ARB_vertex_program2 and/or ARB_fragment_program2 ?
You are my last hope. I am pissed off very hard by OpenGL and i hope that there is perhaps a possibility to code that stuff, even if there still is no specs about it (the implementation seems to be there in both NVidia AND Ati Drivers).
05-15-2003, 03:57 AM
I'm sorry but I haven't got that much experience with floating-point framebuffers.
I suggest that you post a topic on the advanced forum instead. You will have better replies there, and maybe replies from guys working at ATi or nVidia.
05-15-2003, 04:08 AM
It would be very cool, if u could link this thread in the advanced forum please. I can't register at the moment.
Please help me, because i'm stuck at the moment and can't do anything (without using vendor-specific extensions).
Thanks in advance.
05-15-2003, 08:43 AM
You won't be able to have a floating point framebuffer on the current hardware (GeForceFX/Radeon 9500+), only floating point pbuffers.
The precision in ARB_fragment_program is required to be at least 24 bit floating point per color channel so you shouldn't have any precision issues when using ARB_fragment_program.
There is no ARB_vertex_program2 extension yet so the only way you'll be able to access branching in the vertex program is to use the NV_vertex_program2 extension.
05-15-2003, 08:46 AM
"Thanks, but i know the ARB_fragment_program. It sucks on mantissa and exponent. I know this kind of shaders very well from dx 8.1, but i do not like them."
Just so you know, ARB_fragment_program is quite a bit different from DX8 level pixel shaders, its more equivalent to DX9 PS2.0+ shaders.
Originally posted by jra101:
...Just so you know, ARB_fragment_program is quite a bit different from DX8 level pixel shaders, its more equivalent to DX9 PS2.0+ shaders.
I always thought functionality-wise it's like a DX8.5 (no branch). If you are referring to the interface used... don't know.
BTW, I don't exactly understand where's the point of that post. It starts with flow control (and **you can simulate flow control using muls**) then it goes to float buffers. What do you want to do with float buffers? As far as I know, there should be no problem with them. As jra101 said, floating point pixel formats are actually not displayable but they can be used as rendertargets.
05-15-2003, 09:01 AM
"I always thought functionality-wise it's like a DX8.5 (no branch). If you are referring to the interface used... don't know"
There's no branching in the DX9 PS2.0 or PS2.0+ shaders either.
So what new things does VP/FP programmability introduces in DX9?
EDIT: maybe there's in VP but not on FP?
[This message has been edited by Obli (edited 05-15-2003).]
05-15-2003, 09:11 AM
Yes, branching based on constants is available in DX9 vs2.0 shaders.
DX9 introduces increased program lengths for pixel and vertex shaders as well as significantly increased flexibility in the pixel shaders.
05-15-2003, 09:52 AM
Thank you all for the responses. I did not know, that it is possible to use a floating point pbuffer and then just display it with the arb_fragment_progam extension. I thought it is analog to dx 8.1 with low-precision. Cool, so OpenGL does have a usable float buffer on ARB level.
The flow control just because i was tired of writing 20 fragment shaders and then 200 vertex shaders that could have also been 20 or so with branching.
But i can wait for branching until gl2 comes out, i have my old dx 8.1 vertex shaders ready and they can be converted very easily.
Thanks you helped me a lot.
[This message has been edited by Tom78 (edited 05-15-2003).]
But... how do you manage to do a float pbuffer by using ARB? As far as I know there's only NV and ATI extensions avaiable (sorry for putting you off track).
Uhm, I have to thank you to let me focus on this. I always thought DX has branching but looks like it's not (web confirms it).
So, branching on constants (bad) only on vps... booh-hoo! I guess how they'll manage to do procedural texturing. Quite happy to see that GL+vendor extensions are actually beyond DX... I found rumors on the net about DX9.1 with branching everywhere on everything. Wow.
BTW, do we know if R300 supports full branching as nv30? (looking at nv_vp2 and nv_fp looks it can)
EDIT: whoops, can't do float pbuffers on arb.
[This message has been edited by Obli (edited 05-15-2003).]
05-15-2003, 11:24 AM
You have to use vendor-spcific formats, but you can use them together with the arb_fp extension or did i understand something wrong ? That would be not so bad, as long as i have an unified language AND floating point precision.
As far as i understood, i will be able to use an ATI or NV pbuffer to render to and then just display it. Seems to be no problem as far as i did not understand something wrong.
05-15-2003, 12:07 PM
In the vertex program, R3XX (Radeon 9500+) supports branching based on constants, NV3X (GeForce FX 5200+) supports full branching.
In the pixel shader, neither NV30 or R300 support branching. NV30 does have something called condition codes which allow you to do simple if statements in the fragment program. This is exposed in the NV_fragment_program extension, not sure if its exposed in DX9.
I think in d3d9 ver.2+ pixel shaders it supports that kind of branching you mentioned. The ver.2+ and 3 are very similar, except for texture access in vs in 3. It seems that whole version are for ati and '+' versions are nvidia's.
Powered by vBulletin® Version 4.2.2 Copyright © 2013 vBulletin Solutions, Inc. All rights reserved.