Jump to content

  • Log In with Google      Sign In   
  • Create Account


RenHoek

Member Since 07 Jul 2006
Offline Last Active Sep 13 2013 05:52 PM
-----

Topics I've Started

Correct orphaning of mapped buffer data

07 August 2013 - 06:44 PM

Hi guys

 

So I have a uniform buffer which I use for material constants.

This does not change very often, but it does change from time to time.  Which means I need to update the buffer contents sometimes during the course of a render.

The following shows a snippit from my refreshUniforms() function.

When exectuted first, it creates the uniform buffer.  And for all other executions, it simply updates the uniform buffer  ( with care to avoid Implicit synchronization )

 

There are two ways I have this implemented ATM.

 

1)  orphaning

 

if ( m_uniformBuffer == 0 )

{

  // init the buffer

  glGenBuffers( 1, &m_uniformBuffer );                                            //  create new buffer
  glNamedBufferDataEXT(m_uniformBuffer, bufferSize, buf.get(), GL_STATIC_DRAW);   //  upload new data

}

else

{

  // refresh the buffer

  glNamedBufferDataEXT(m_uniformBuffer, bufferSize, NULL, GL_STATIC_DRAW);        //  orphan prev data
  glNamedBufferDataEXT(m_uniformBuffer, bufferSize, buf.get(), GL_STATIC_DRAW);   //  upload new data

}

 

2)  Via Map/UnMap

 

if ( m_uniformBuffer == 0 )

{

  // init the buffer

  glGenBuffers( 1, &m_uniformBuffer );                                        //  create buffer
  glNamedBufferDataEXT(m_uniformBuffer, bufferSize, NULL, GL_DYNAMIC_DRAW);   //  initialise

}

else

{

  //  orphan prev data

  glNamedBufferDataEXT(m_uniformBuffer, bufferSize, NULL, GL_DYNAMIC_DRAW);    // is this line needed?

}

 

//  upload new data
GLvoid* data = glMapNamedBufferEXT( m_uniformBuffer, GL_WRITE_ONLY );
memcpy( (void*)data, (const void*)buf.get(), bufferSize );
bool mapResult = glUnmapNamedBufferEXT( m_uniformBuffer );

 

 

Question

 

I was previously performing option 1.  But need to move to option 2 due to a driver issue.  dont ask... : (

So my question...

It is necessary to perform orphaning for option 2?

If so, why?  Shouldn't the driver manage the uploading of the memory for me?  At the right time?

 

Cheers!

Ren


GL_FRAGMENT_SHADER_DERIVATIVE_HINT Is this useful anymore?

17 July 2013 - 10:01 PM

GL_FRAGMENT_SHADER_DERIVATIVE_HINT

This hint apparently enables high quality ( or low quality ) derivatives in fragement shaders.

 

Does anyone know if this actually does _anything_ on modern hardware?

( eg Nvidia cards etc... )

 

Anybody know anything about this hint?

I see very little discussion about it anywhere on the internet.  :(

 

Thanks!

Ren

 


Looking for a good+solid implementation of TomF's vertex-cache-optimization algorithm

31 October 2012 - 04:01 AM

Hi all

I'm coding for modern CPU's.
But the meshes I'm sending to the graphics card are pretty much directly output from Maya. I guess they will have poor vertex-cache-ordering.
I'm hoping to use a vertex-cache-optimization pre-pass on the meshes to gain some performance. As suggested here
http://home.comcast.net/~tom_forsyth/papers/fast_vert_cache_opt.html

Does anyone know of the best technique to use on modern cards? Is it still Toms algorithm? The models I have to render have 1,000,000+ triangles. :(
So I would like the pre-pass to run fast, as well as produce good results. ( like Toms algorithm )

2nd Question.
Does anyone know of a solid and good implementation of Toms algorithm? The ones I'm finding on the internet seem to be from junior/hobby programmers who are not writing the most efficient code.

Thanks all
Ren

Notes+Questions on Perlin noise and its derivatives

24 February 2012 - 04:09 AM

Hi all

I'm currently doing a lot of work with GPU procedural noise in GLSL.
Here are a few questions + notes regarding this.

1) Noise Derivatives
One area I'm working on right now is calculating analytical derivatives for various noises.

Inigo Quilez posted some notes on how to calculate the derivatives of value noise. ( although he incorrectly calls it perlin noise )
=> http://www.iquilezles.org/www/articles/morenoise/morenoise.htm
( This noise derivative is extremely easy and fast to implement in GLSL. More so that what Inigo has posted in his CPU version. Let me know if you want it and I can post )

Inigos approach does not work for Perlin noise. Some people have incorrectly implemented it thinking that it does.
=> https://github.com/cinder/Cinder/blob/master/src/cinder/Perlin.cpp [ NOTE: INCORRECT! ]

I have only seen one correct implementation of perlin noise with derivatives. Although it is only in 2D.
=> http://www.decarpentier.nl/scape-procedural-extensions

Perlins Simplex noise allows for a easy derivative calculation, as kindly demonstrated by Stefan Gustavson here...
=> http://webstaff.itn.liu.se/~stegu/aqsis/flownoisedemo/

So my question / request is if anyone has implemented Classic Perlin Noise with Analytical derivatives in 3D? Or do they know of any implementations? Thanks!

2) Normalizing Classic Perlin noise to -1.0->1.0
I've noticed a few threads on the internet of guys trying to figure out how to normalize perlin noise to a -1.0->1.0 range.
eg => http://www.gamedev.net/topic/285533-2d-perlin-noise-gradient-noise-range--/
This particular thread goes on for a _very_ long time. It boggles my brain how much time they put into this thred. Sorry if they finally got the answer, or that I maybe missed the point of the thread, but I didn't have time to read it all.

For me it was a very easy thing to solve so I'll post my answer here for anyone who is interested.

The way to do it is to imagine the maximum possible value which could be generated by the perlin noise algorithm.
In 2D this would be having all 4 ( normalized ) gradient vectors pointing to the very center of the square, and the sample being taken from the center of that square. This generates a value of sqrt( 0.5 ) = 0.70710678.....
So the normalization value to scale the noise to a -1.0->1.0 range is 1.0/sqrt(0.5)
In 3D it is 1.0/sqrt(0.75)

Easy! :)

Ok. Thanks all
Ren Hoek

Floating Point Precision in pixel shader

08 October 2011 - 06:04 PM

Hi guys

So I'm working on some stuff atm which requires random numbers within a pixel shader.
I'm aiming for DX9 hardware so integer hashing is not an option.
I've opted for a floating point hash from the x,y integer pixel coordinate of the form

hash = mod( x*x*y*y, SOMEPRIME ) / SOMEPRIME

I seem to be getting good results from it. ( I can clamp and offset the domain to avoid the reflection along the x=y diagonal line )

Thing is, the x*x*y*y operation pushes the floating point integer coordinate way past ( 2 << 23 ). So the floating point number starts to loose precision.
eg, x = 99.0 y = 99.0 99.0^4 > 2.0^23

So my questions.
Do modern graphics cards conform to the IEEE 32bit floating point standard?
Are there any that do not? ( I think I remember some ATI cards being 24 bit at some point... )
Can I expect this function to produce the same results across different cards? At least the ones which are IEEE 32bit FP compliant right?

thoughts?

Thanks all!
Ren

PARTNERS