On Mon, Oct 4, 2010 at 1:38 PM, Robert Osfield <[email protected]>wrote:

> Hi Tim,
>
> Thanks for your patience and updating the submission.  I haven't yet
> purchased myself a new card.  I'll order one this week and finally
> I'll have the ability to test and dive into this topic.
>
> Cheers,
> Robert.
>
> It's no problem. FYI, uniform buffer objects don't require a DX11 card. I'm
doing my work with an NVidia 8600m.

Tim


> On Mon, Oct 4, 2010 at 6:14 AM, Tim Moore <[email protected]> wrote:
> > Hi Robert,
> > I'm resubmitting my Uniform Object Buffer patch against the current
> sources,
> > as I fear the original may have gone a little stale. Also, I'm not sure
> if
> > you were waiting for me to implement more of the "to do" list I included;
> I
> > haven't done that yet, as I've been waiting on the patch to be committed
> :)
> > Thanks,
> > Tim
> >
> > On Thu, Jul 15, 2010 at 11:34 AM, Tim Moore <[email protected]> wrote:
> >>
> >>
> >> On Thu, Jul 15, 2010 at 11:19 AM, Robert Osfield
> >> <[email protected]> wrote:
> >>>
> >>> Hi Tim,
> >>>
> >>> I haven't yet looked at the submission so can't comment too much on
> >>> the approach.  I was a bit surprised that that it was a StateAttribute
> >>> approach, as I was expecting something more closely aligned to the
> >>> current osg::Uniform support.
> >>>
> >> Yeah, me too, but the the buffer bindings are global state and not
> >> something that needs to be set per program.
> >>>
> >>> However, I'm not too familiar with the uniform blocks so I wouldn't
> >>> worry about my own expectations too much - I will have to dive into
> >>> the OpenGL feature, your submission and gets some hardware+drivers
> >>> that support uniforms blocks to learn about them myself.  Now that
> >>> NVidia have released a well balanced Fermi card I'll be upgrading to
> >>> get myself some fully capable hardware, then I'll just have to work on
> >>> the other distractions...
> >>>
> >> FYI, I'm doing the work on a 8600M. They are a core part of OpenGL 3.3,
> >> which is (well?) supported on that generation of cards.
> >>
> >>>
> >>> At my end I'm juggling a couple of different tasks, some client work
> >>> improving 3D text support, shader composition and family commitments -
> >>> it's school holidays now so lots days out of the office.
> >>> Unfortunately this does mean that I don't have many slots available to
> >>> dive into other topics.  So if you feel comfortable with the approach
> >>> your taking go for it, I'll try to get back and review the changes as
> >>> soon as I can.
> >>>
> >>> Thanks for you patience,
> >>> Robert.
> >>>
> >> No prob.
> >> Tim
> >>
> >>>
> >>> On Thu, Jul 15, 2010 at 9:30 AM, Tim Moore <[email protected]>
> wrote:
> >>> > Hi Robert,
> >>> > I'm wondering if you've had any chance to take a look at this
> >>> > submission. I
> >>> > know that you're heads-down in shader composition and probably don't
> >>> > want to
> >>> > want to think about any large submission, especially one that touches
> >>> > state
> >>> > management. However, this doesn't touch State, StateAttribute etc. in
> >>> > any
> >>> > fundamental way. I ask because I'm thinking of going forward in two
> >>> > directions with this: filling in the missing features, and using the
> >>> > same
> >>> > approach to support transform feedback buffers. Do you have any
> >>> > comments on
> >>> > the basic approach?
> >>> > Thanks,
> >>> > Tim
> >>> >
> >>> > On Wed, Jun 30, 2010 at 9:07 AM, Tim Moore <[email protected]>
> wrote:
> >>> >>
> >>> >> Hi,
> >>> >> Here is initial support for uniform buffer objects. The binding
> >>> >> between a
> >>> >> buffer object and an indexed target is implemented as a new
> >>> >> StateAttribute,
> >>> >> UniformBufferBinding. I've included an example program based on the
> >>> >> code in
> >>> >> the ARB_uniform_buffer_object specification.
> >>> >> A few things remain to do:
> >>> >> * The binding between a uniform block in a shader program and a
> buffer
> >>> >> indexed target number is fixed, like a vertex attribute binding.
> This
> >>> >> is too
> >>> >> restrictive because that binding can be changed without relinking
> the
> >>> >> program. This mapping should be done by name in the same way that
> >>> >> uniform
> >>> >> values are handled i.e., like a pseudo state attribute;
> >>> >> * There's no direct way yet to query for the offset of uniforms in
> >>> >> uniform
> >>> >> block, so only the std140 layout is really usable. A helper class
> that
> >>> >> implemented the std140 rules would be quite helpful for setting up
> >>> >> uniform
> >>> >> blocks without having to link a program first;
> >>> >> * There's no direct support for querying parameters such as the
> >>> >> maximum
> >>> >> block length, minimum offset alignment, etc. Having that information
> >>> >> available outside of the draw thread would make certain instancing
> >>> >> techniques easier to implement.
> >>> >> Tim
> >>> >
> >>> >
> >>> > _______________________________________________
> >>> > osg-submissions mailing list
> >>> > [email protected]
> >>> >
> >>> >
> http://lists.openscenegraph.org/listinfo.cgi/osg-submissions-openscenegraph.org
> >>> >
> >>> >
> >>> _______________________________________________
> >>> osg-submissions mailing list
> >>> [email protected]
> >>>
> >>>
> http://lists.openscenegraph.org/listinfo.cgi/osg-submissions-openscenegraph.org
> >>
> >
> >
> > _______________________________________________
> > osg-submissions mailing list
> > [email protected]
> >
> http://lists.openscenegraph.org/listinfo.cgi/osg-submissions-openscenegraph.org
> >
> >
> _______________________________________________
> osg-submissions mailing list
> [email protected]
>
> http://lists.openscenegraph.org/listinfo.cgi/osg-submissions-openscenegraph.org
>
_______________________________________________
osg-submissions mailing list
[email protected]
http://lists.openscenegraph.org/listinfo.cgi/osg-submissions-openscenegraph.org

Reply via email to