Buffer Shaders

whoops, yeah :wink:
Didn’t have a chance to play with this, so i mentally dump it together with atomics. Doesn’t change the fact that features disabling caching are only a few.

Hmmm, not really. We can do bit shifting and type ‘casting’ so functionally (with glsl) we are all set already.

For performance reasons, we probably would need them, but i dont think this would be ~60. Im sure ARB could come up with slick api that would be small and pretty :wink:

But yeah, programmable means slower, and i cant imagine that much work in the puller stage id like to do to justify it. Perhaps hw vendors may justify that expenditure, if we go to far with format counts that need to be supported.

Didn’t have a chance to play with this, so i mentally dump it together with atomics. Doesn’t change the fact that features disabling caching are only a few.

Atomics would do the exact same thing. Atomics is not just about atomically incrementing a variable; you can read from an atomic location and do computations based on it.

In any case, between uniform buffers, buffer textures, and image_load_store, you can do pretty much whatever vertex fetching you want. You just have to pay the price in terms of performance. I don’t see what any special API would do to change that price, since the price is, more or less, based on hardware.

[quote=“Ilian_Dinev”]

image_load_store :slight_smile:
But anyway, the greatest argument was that it destroys the HW-accelerated attrib-fetch. And there’s the problem of - attribute formats, almost 60 of them :slight_smile: . Will need lots of built-in glsl functions to be added to decompress them. And if certain gpus don’t have hw-accelerated attribfetch (modern Radeons iirc), the custom fetch will definitely have more overhead than what the drivers have for “fixed-func”. (e.g. grouping DMA requests in interleaved-attribs nicely, calculating addresses more efficiently) [/QUOTE]

With the packing and unpacking functions we have access to that part of the hardware.

With the packing and unpacking functions we have access to that part of the hardware.

No, you have access to the ability. That doesn’t mean you’re hooked into the optimized attribute loading path. You simply can call GLSL functions that unpack values into floats. That’s not the same thing as using the hardware’s free attribute conversion scheme.

“hardware’s free attribute conversion scheme”

There is nothing free in hardware :stuck_out_tongue:

True for OpenGL 3 hardware but I am not sure if it’s still the case.