Sharing Vertex/Fragment Programs across Rendering Contexts

It should be possible to share vertex and fragment programs across multiple rendering context in the exact same manner as with texture objects, right ?

Running on a Radeon 9700, I can get textures to share just fine but unless I create the vertex/fragment programs in the pbuffer context, they refuse to work. No errors are generated in either context.
I even managed to get a 128-bit floating point buffer to work when the programs are created in the pbuffer context ( too bad blending doesn’t work with that ).

Originally posted by PH:
[b]It should be possible to share vertex and fragment programs across multiple rendering context in the exact same manner as with texture objects, right ?

Running on a Radeon 9700, I can get textures to share just fine but unless I create the vertex/fragment programs in the pbuffer context, they refuse to work. No errors are generated in either context.
I even managed to get a 128-bit floating point buffer to work when the programs are created in the pbuffer context ( too bad blending doesn’t work with that ).[/b]

Theres a driver bug that prevents it from being shared. It happens with the VAO extension too (only more problematic).

I wasn’t aware of the VAO problem. I hope that’s something ATI can/will fix soon. Why do you call the VAO issue more problematic ? Do you mean it’s harder for ATI to resolve it ?

[This message has been edited by PH (edited 12-07-2002).]

I think I see what you mean - multiple contexts are not mentioned in the spec. Arrgh . Well, I guess we’ll have to wait for the ARB_VAO spec to be finalized.

Yes, the spec requires that vertex and fragment programs are shared with ShareLists().

Regarding blending, the way to do that is to ping-pong between two floating point buffers, and sample the other buffer with fragment.position as the texture coordinate. If you want to share a depth buffer (Good Idea ™), you have to create a double-buffered pbuffer context, and use the front and back buffers as your ping and pong floating point color buffers.

I have not actually implemented this idea yet, so I don’t know what the problems are with getting it working (except for the sharing you just mentioned).

Originally posted by jwatte:
I have not actually implemented this idea yet, so I don’t know what the problems are with getting it working (except for the sharing you just mentioned).

I think it was discussed here at one time but the problem was that you couldn’t render to any color buffers if one was bound to a texture ( not 100% sure but I think that’s what the spec says ).

Originally posted by PH:
[b]I wasn’t aware of the VAO problem. I hope that’s something ATI can/will fix soon. Why do you call the VAO issue more problematic ? Do you mean it’s harder for ATI to resolve it ?

[This message has been edited by PH (edited 12-07-2002).][/b]

I’m pretty sure it’s fixable.

The VAO is more problematic because it actually causes the app to crash (at least it does last I tried), with ARB_f_p it just doesn’t work.

Thanks for the info. Maybe I should try it out and see if it fixed in the latest beta drivers.

I hit this bug yesterday, had some serious trouble getting stuff to work. I finally figured it out to be a driver bug.
NitroGL, I assume you have reported this to ATi? I was going to do that, but now that I see this topic I suppose they may already know it.

The shared lists issue with vertex/fragment program was discovered a little while ago. A fix will be available soon.

-Evan

Thanks, that’s good to know. How would you implement multipass with floating point buffers ? Two seperate pbuffers that alternate between read and write ?

Edit: Hmm, that would require 2 depth buffers. Will the ATI_draw_buffers extension be the right way for this ? And if so, when will it be available ?

[This message has been edited by PH (edited 12-08-2002).]

Another quick question: offscreen pbuffers with multisample should work too, right ? Btw. the glSampleCoverageARB funtion is missing from the ATI drivers ( that is, the ARB ending is missing ).

The last time I checked we were not exporting the multisample extension string, so I don’t think we would need to export that entry-point. That said, I believe we should be exporting that extenion/entry-point. I need to check.

On draw buffers, expect it very soon. I need to think about the current solution to your issue. We are working on a good general solution to the problem.

-Evan

Thanks, that sounds great.

I was curious so I fiddled around with the ATI_draw_buffers extension and managed to get it to work using auxiliary color buffers and a fragment program option.

That is, multiple outputs from the fragment program, I haven’t tried reading from them ( if at all possible ).

ehart,

With the general solution you are working on, will the following be possible,

(1) Creating a number of auxiliary color buffers without any front/back buffers. What about pbuffers without any color buffers ( for shadow maps ) ?

(2) Being able to read from one color buffer bound as a texture and still be able to write to another color buffer of the pbuffer ( not bound ).

Is the ARB working on rolling all of this into a new extension ( if so, please include an option for rectangular texture targets for all of the above ) ?