PDA

View Full Version : Shader objects in 51.75?



KRONOS
09-16-2003, 01:25 AM
I just installed the detonator 51.75 and:

1 - there's a big bug with vertex_buffer_object (edit: doesn't matter much, just to let you know...)

2 - I haven't tested this, but function pointers for GL_ARB_occlusion_query can be retrevied. Can enable GL_ARB_point_sprite without errors too.

3 - Wince I have a GF3, GL_ARB_shader_objects function pointers returned NULL. Do any of you FX users interessed? http://www.opengl.org/discussion_boards/ubb/smile.gif

4 - cass, is there something we should know about? http://www.opengl.org/discussion_boards/ubb/wink.gif

[This message has been edited by KRONOS (edited 09-16-2003).]

rgpc
09-16-2003, 03:51 AM
So we can assume you have Win64 & and AMD64? Because these are the only 51.xx drivers that have been "officially" released - and even that as a Beta only...

kehziah
09-16-2003, 04:40 AM
Originally posted by rgpc:
So we can assume you have Win64 & and AMD64? Because these are the only 51.xx drivers that have been "officially" released - and even that as a Beta only...
Are we on a dev forum or what? Beta/unofficial drivers have always been used by developers as they usually contain fixes for known bugs, which helps developers to move on. Nobody here will ever complain about experimental/early implementation of new stuff like shader objects not being rock stable in a beta.
Getting feedback is good for IHVs, as shown by the presence of some of their employees on this board. I fail to see the problem of discussing problems/changes in a new driver release, even if it's a beta.

cass
09-16-2003, 04:45 AM
KRONOS,

I don't think I can help without more information. What sort of VBO problem are you having?

Thanks -
Cass

KRONOS
09-16-2003, 05:11 AM
Thanks cass but I do not have problems. I said that there was a bug so that people would be aware of that. I know they're beta, but normally here that doesn't matter much. Anyways, the bug is somewhere in the sync. If I do not uptade a buffer, it's fine, if I change the data dynamically I get weird results. But you are probably aware of this...

I guess there is probably a lot of people waiting for the shader objects, and maybe they could do something with them with these driver set. Like what happened with vertex_buffer_object. They were not on the extension string, but we could use them anyway...

"cass, is there something we should know about?"
I was expecting an answer like: "Yes, you can mess with glSLang with these drivers. There are still bugs, but you can use it" http://www.opengl.org/discussion_boards/ubb/wink.gif



So we can assume you have Win64 & and AMD64?


.....

[This message has been edited by KRONOS (edited 09-16-2003).]

rgpc
09-16-2003, 03:41 PM
Originally posted by kehziah:

Beta/unofficial drivers have always been used by developers as they usually contain fixes for known bugs, which helps developers to move on. Nobody here will ever complain about experimental/early implementation of new stuff like shader objects not being rock stable in a beta.

Obviously someone has complained about a Beta release. But the list of released beta drivers only included one 51.xx driver (and now one 52.xx) and that was a Win64/AMD64 driver.

That aside, this isn't the forum for complaining about the problems in a Beta/Leaked version of drivers.

Zengar
09-16-2003, 09:10 PM
Well, I downloaded 51.75 and it's working rather good on my WinXP: + 15% fragment shader performance.
From where do you have that stuff with win64?

rgpc
09-16-2003, 09:18 PM
nVidia registered developer login.

Where did you download 51.75 from?

KRONOS
09-17-2003, 01:32 AM
From 3dchipset.com

rgpc
09-17-2003, 03:25 AM
From 3dChipset.comI want to say thanks to the folks who are mirroring these files we leaked. Thanks goes to viper at Tech Connect, [AIX]Hood at File Rush, Nazgul on his server, and AzraeL Tek Xtreme for helping mirroring the WinXP & Win2k Beta 51.75 Detonator driver. Hats off to you fella's for contributing...

And you wonder why you have problems?

M/\dm/\n
09-17-2003, 09:59 PM
Well, I I like the interface & adittional features of 50, seems that OC auto detect isn't working. Performance has increased in all apps from 15-30%, I'll try to check IQ today http://www.opengl.org/discussion_boards/ubb/biggrin.gif Didn't had time to check my own apps though.

azazello
09-19-2003, 12:42 AM
Look like glAccum have hardware support in this driver. Additionally, it has bug in glAccum.

additional changes in 51.75
GL_ARB_point_sprite
GL_SUN_slice_accum

*ARB_fragment_program*
*Max. program env. parameters* 256 (was 128)
*Max. program local parameters* 256(was 128)

hidden extensions(nv34)
NV_fragment_program2
NV_vertex_program3
NV_program_registers

azazello
09-19-2003, 12:50 AM
additional flag "Stinger emulated" - maybe this is GLSlang?.

But it's impossible to switch it on by stndard methods(via registry).

KRONOS
09-19-2003, 07:37 AM
GL_ARB_occlusion_query works...
Already changed everything to this...

Zengar
09-19-2003, 08:58 AM
Originally posted by ayaromenok:

hidden extensions(nv34)
NV_fragment_program2
NV_vertex_program3
NV_program_registers



never heard of it...

Zengar
09-19-2003, 09:02 AM
Googled about "stinger". It is very remarkable. Stinger is the codename of R300!

esw
09-19-2003, 09:11 AM
ayaromenok,

Can you give more details on the bug you're seeing in glAccum?

~Eric

azazello
09-19-2003, 01:01 PM
2esw
You can see a wrong execution of
accconvolve.c SIGGRAPH 97: Programming with OpenGL: Advanced Techniques http://www.sgi.com/software/opengl/advanced97/programs/programs.html

image filter in this example implemented with glAccum, but with 51.75 it's not work.

2Zengar
hidden extensions(nv34)
NV_fragment_program2
NV_vertex_program3
NV_program_registers
>>never heard of it..
Not only you.:-) Nevertheless this strings coexist inside nvoglnt.dll together with NV_fragment_program & NV_vertex_program/2.

azazello
09-19-2003, 01:44 PM
I check a bit more carefully - new targets:!!FP2.0 !!VP3.0
But nothing related to GLSlang:-(

esw
09-19-2003, 02:17 PM
ayaromenok,

accconvolve uses a single-buffered window. The rendering doesn't appear because it never calls flush. If you add a flush after glAccum(GL_RETURN), the app should work correctly (it does for me).

It worked in software because software doesn't batch any commands.

~Eric

azazello
09-19-2003, 02:45 PM
2esw
Right, it works for me two, but with Detonator 40(and many other GL implementation) it works without glFlush. (Generally, I didn't check source code, just run binary again).

from spec - "The RETURN operation .. . The resulting color value is placed in the buffers currently enabled for color writing as if it were a fragment produced from rasterization.." - looks like glFlush() not really required.

Anyway, it works much better than in Det40(even with a small code modification)..

esw
09-19-2003, 03:08 PM
An operation is not guaranteed to complete within a finite amount of time unless there is a flush. The same app works on earlier drivers because the software implementation of accumulation buffers don't batch up commands, so it completes immediately.

The fragment is being produced as if it were a fragment from rasterization as spec'd - normal rasterization is batched as well and requires a flush in front buffered rendering.

~Eric

M/\dm/\n
09-21-2003, 06:12 AM
Seems that auto detect clock speed feature isn't working, when doublescan is enabled most of apps are showing 5x striped screen. Still can't find pixel adressing (topleft corner/center) for D3D.

azazello
09-24-2003, 12:35 AM
This driver add NV40 emulation.
NV_fp2/NV_vp3