haskell-opengl / opengl Goto Github PK

Hello! Is it possible to update the OpenGL package to use OpenGL 4.x with OpenGLRawgen (https://github.com/Laar/OpenGLRawgen) bindings under the hood?
OGL 3.2 is very outdated right now and it would be nice to allow Haskell users use newer libs.

I've pretty much spent the last few hours hacking around the fact that I can't get at the GLenum's for an arbitrary ParameterizedTextureTarget in order to set up texture swizzling. =(

I basically wanted to:

    glTexParameter t gl_TEXTURE_SWIZZLE_R GL_RED
    glTexParameter t gl_TEXTURE_SWIZZLE_G GL_RED
    glTexParameter t gl_TEXTURE_SWIZZLE_B GL_RED
    glTexParameter t gl_TEXTURE_SWIZZLE_A GL_ONE

This would have been trivial and I could have continued to use the built in abstractions if we acknowledged that our abstractions leak as it is I pretty much had to give up on carrying on the abstraction through my own API.

If

class ParameterizedTextureTarget t where
   marshalParameterizedTextureTarget :: t -> GLenum
   marshalParameterizedTextureTargetProxy :: t -> GLenum
   marshalParameterizedTextureTargetEnableCap :: t -> EnableCap

exported the various marshal functions, I'd have been off to the races. There are dozens of these types sprinkled throughout the library.

What is gained from hiding the implementations of these classes? The ability to bump minor versions when you change how they are implemented?

You have lots of lovely little abstractions sprinkled around the OpenGL library. Please let us build atop them. =)

I'm trying to use VAOs but mac requires the use of apple specific extension functions. Apple's VAO docs. It seems there are apple extension functions in OpenGLRaw What's the best way to integrate this? Double up all VAO functions with *Apple versions?

I'm looking to check the availability / precision of highp, but I can't actually use PrecisionType. It doesn't have any exported constructors, despite being a nice helper type explicitly designed so we can use its constructors. ;)

https://hackage.haskell.org/package/OpenGL-2.9.2.0/docs/Graphics-Rendering-OpenGL-GL-Shaders-ShaderObjects.html

Creating an OpenCL image from an OpenGL texture requires access to the texture ID, which is no longer possible now that TextureObject is abstract.

Separate polygon modes are deprecated nowadays (see e.g. section D.2 of the OpenGL 4.3 spec), so polygonMode should handle this properly: When the given PolygonModes are equal, use FRONT_AND_BACK, otherwise separate FRONT and BACK calls. This way we can keep the signature of polygonMode and use non-deprecated functionality when possible.

Please add

instance Functor GettableStateVar where
  fmap f (GettableStateVar m) = GettableStateVar (fmap f m)

I can define it outside of the package, but it seems particularly bad to have to both needlessly go through the smart constructor and introduce an orphan.

instance Functor GL.GettableStateVar where
  fmap f v = makeGettableStateVar (f <$> get v)

Would you consider exporting the constructors of these data types as well?

Hipmunk uses Data.StateVar, which is basically the OpenGL StateVar but in a different library. This causes a conflict when using OpenGL And Hipmunk together.
Is the OpenGL binding going to stick with the own version or is it also going to use the StateVar library (as implied here http://www.haskell.org/pipermail/beginners/2014-May/013851.html )? At the moment I need to patch Hipmunk to make it work with OpenGL (since doing it the other way round requires patching a load of libs). I'd just like to know who I should propose a patch to, if at all.
Thanks,

I have a project where I'm going to be creating and linking a lot of shaders and programs in a very short period of time.

The current OpenGL bindings protect me from myself and prevent me from deleting a bad shader after I miscompile it, and from deleting a shader I'm not going to use further, etc.

There is also no way to get out the GLuint for the underlying shader resource.

This is forcing me into the raw bindings, but worse I can't interop between the two because all of the shader support in the high level bindings is opaque for some reason, so I can get no benefit from the nice high level bindings at all.

OpenGL 3.0 spec section 2.15

quoting appendix N.1 'New Features' from the OpenGL 3.0 spec:
"Multisample stretch blit functionality (GL_EXT_framebuffer_multisample and GL_EXT_framebuffer_blit)."

The version of OpenGL included in the Haskell Platform (OpenGL 2.2.3.1) has a known "vertexAttribPointer undefined" bug:

http://www.haskell.org/pipermail/hopengl/2009-July/000873.html

It is apparently easy to fix (remove the "undefined" line as per the previous post).

This is a major "show stopper" bug because it makes it impossible to use OpenGL shaders with the Haskell Platform => can't demonstrate how useful and practical the Haskell Platform is for creating modern looking games.

(OpenGL 2.3.0 has fixed the issue - post here:)

http://www.digipedia.pl/usenet/thread/14388/1387/

Is there any conceptional reason that Graphics.Rendering.OpenGL.GL.FramebufferObjects.RenderbufferObject isn't an instance of Eq, Ord and Show? Other OpenGL ID wrappers deriving these instances?

A pull request is coming soon ;)

The hackage server can be a bit flaky about building packages. If it has trouble building any of the opengl packages then we should host the haddocks somewhere else (github?) and link to them from the package description.

In Polygons.hs, polygonMode's type signature is:

polygonMode :: StateVar (PolygonMode, PolygonMode)

However, in all documentation from 1.5 and above in the OpenGL the prototype for the PolygonMode function is:

void PolygonMode(enum Face, enum Mode);

The correct type signature for polygonMode should be then:

polygonMode :: StateVar (Face, PolygonMode)

The existing extension string functionality is deprecated in modern OpenGL, would be nice if something along the lines of this could be added to the wrapper:

getNumExtensions :: IO Int
getNumExtensions =
    alloca $ \(ptr :: Ptr GLR.GLint) ->
        GLR.glGetIntegerv GLR.gl_NUM_EXTENSIONS ptr >> fromIntegral <$> peek ptr

getExtensionStr :: Int -> IO String
getExtensionStr i =
    peekCString =<< castPtr <$> GLR.glGetStringi GLR.gl_EXTENSIONS (fromIntegral i)

getGLExtensionList :: IO [String]
getGLExtensionList =
  getNumExtensions >>= \numExt -> forM [0..numExt - 1] $ \i -> getExtensionStr i

I can't find any function for performing a glUniformMatrix*.

Hackage2 is missing docs for OpenGL 2.9.1.

Due to the latter's capitalized CMYKA module.

Configuring OpenGL-2.8.0.0...
Building OpenGL-2.8.0.0...
Preprocessing library OpenGL-2.8.0.0...

Graphics/Rendering/OpenGL/GL/Hints.hs:25:8:
    Could not find module ‘Graphics.Rendering.OpenGL.Raw.EXT.Cmyka’
    Perhaps you meant
      Graphics.Rendering.OpenGL.Raw.EXT.CMYKA (from OpenGLRaw-1.5.0.0)
      Graphics.Rendering.OpenGL.Raw.EXT.ABGR (from OpenGLRaw-1.5.0.0)
      Graphics.Rendering.OpenGL.Raw.EXT.BGRA (from OpenGLRaw-1.5.0.0)
    Use -v to see a list of the files searched for.

We're currently actively working on writing better SDL 2 bindings in sdl2.

For various reasons, it can't depend on the OpenGL package directly, but it needs a state variable construction.

Sadly, not every platform with SDL 2 has OpenGL -- thanks Microsoft.

We'd like to depend on the StateVar package, but then we'll get two versions of the notion of a StateVar that conflict.

By far the cleanest option for us moving forward would be if OpenGL switched to using the external StateVar package that you also maintain, then we could incur a dependency on that.

I realize that when this was last proposed there was some pushback from the Haskell Platform, but otherwise what we're going to start seeing is a profusion of almost-compatible APIs, which is the very thing that the Haskell Platform is meant to prevent.

As we are implementing tne functionality of OpenGL 3 we should look at what we do with the deprecation model that comes with that version.
Dagit suggested marking the deprecated functions, modules, etc. with deprecation/warning flags to notify the user at compile time.

I personally prefer some measures that are quite a bit stronger and suggest that we move the deprecated functions to its own namespace, say ...GL.OpenGL.Deprecated. This would mean quite a lot of refactoring, but the upside is that the two are much more separated from each other than they now are. Though this would include a major break in the code, so we should carefully consider this.
If we would take such action it might be a good idea to idea to restructure quite a bit more of the package as there are some more problems in my opinion.

There's no way to create a rectangular texture with the high level api. texImage2D only calls the low level api with Texture2D, not TextureRectangle.

It seems that the old version in HP can be easily ported to latest GHC 7.4, in case maintainer wanted to release a 2.2.3.1 package. May be nice since for some strange reasons cabal defaults to OpenGL 2.2.3.0, if installed on vanilla GHC 7.4.1.

Some tokens need to be added (as they are updated), see appendix N.3 from the OpenGL3.0 spec
COMPARE_REF_TO_TEXTURE
MAX_VARYING_COMPONENTS
MAX_CLIP_DISTANCES
CLIP_DISTANCEi

From HOpenGL mailing list: http://www.haskell.org/pipermail/hopengl/2013-July/001055.html

When I try to run OpenGL examples on Ubuntu 12.04 with the latest
Haskell platform (2013.2.0.0, incl. GHC 7.6.3), the following happens:

svenpanne@svenpanne:~/haskell-platform-2013.2.0.0/packages/GLUT-2.4.0.0/examples/RedBook$
runhaskell Smooth.hs
freeglut (Smooth.hs):  ERROR:  Internal error <FBConfig with necessary
capabilities not found> in function fgOpenWindow
X Error of failed request:  BadWindow (invalid Window parameter)
  Major opcode of failed request:  4 (X_DestroyWindow)
  Resource id in failed request:  0x0
  Serial number of failed request:  37
  Current serial number in output stream:  40

I am using an x86_64 Ubuntu 12.04 distro (with some minor corporate
modifications, but they probably don't matter here) with NVIDIA
drivers. This means that the dynamic linker will load NVIDIA's
libGL.so, as can be seen e.g. here:

svenpanne@svenpanne:~$ ldd /usr/lib/x86_64-linux-gnu/libglut.so | grep libGL
libGL.so.1 => /usr/lib/nvidia-current/libGL.so.1 (0x00007f1ddc76e000)
svenpanne@svenpanne:~$ dpkg -S /usr/lib/nvidia-current/libGL.*
nvidia-current: /usr/lib/nvidia-current/libGL.so
nvidia-current: /usr/lib/nvidia-current/libGL.so.1
nvidia-current: /usr/lib/nvidia-current/libGL.so.310.51

This is OK, and this is the libGL.so which will be found by 'ld' when
one simply specifies '-lglut' for compilation via gcc. This can be
seen e.g. when tracing things during the linking stage of the "Hello,
world!" example from the Red Book:

svenpanne@svenpanne:~/redbook$ strace -f gcc hello.o -lglut 2>&1 |
grep 'libglut\|libGL' | grep -v ENOENT
[pid  7782] stat("/usr/lib/gcc/x86_64-linux-gnu/4.6/../../../x86_64-linux-gnu/libglut.so",
{st_mode=S_IFREG|0644, st_size=287720, ...}) = 0
[pid  7782] open("/usr/lib/gcc/x86_64-linux-gnu/4.6/../../../x86_64-linux-gnu/libglut.so",
O_RDONLY) = 8
[pid  7782] open("/usr/lib/gcc/x86_64-linux-gnu/4.6/../../../x86_64-linux-gnu/libglut.so",
O_RDONLY) = 13
[pid  7782] stat("/usr/lib/nvidia-current/libGL.so.1",
{st_mode=S_IFREG|0644, st_size=1099504, ...}) = 0
[pid  7782] open("/usr/lib/nvidia-current/libGL.so.1", O_RDONLY) = 14
[pid  7782] open("/usr/lib/gcc/x86_64-linux-gnu/4.6/../../../x86_64-linux-gnu/libglut.so",
O_RDONLY) = 5
[pid  7782] open("/usr/lib/nvidia-current/libGL.so.1", O_RDONLY) = 12
[pid  7782] open("/usr/lib/gcc/x86_64-linux-gnu/4.6/../../../x86_64-linux-gnu/libglut.so",
O_RDONLY) = 8
...

But things get weird when one explicitly specifies '-lGLU and -lGL' in
addition to '-lglut' (something GHC's package system is actually doing
behind the scenes, too):

svenpanne@svenpanne:~/redbook$ strace -f gcc hello.o -lglut -lGLU -lGL
2>&1 | grep 'libglut\|libGL' | grep -v ENOENT
[pid  7943] stat("/usr/lib/gcc/x86_64-linux-gnu/4.6/../../../x86_64-linux-gnu/libglut.so",
{st_mode=S_IFREG|0644, st_size=287720, ...}) = 0
[pid  7943] open("/usr/lib/gcc/x86_64-linux-gnu/4.6/../../../x86_64-linux-gnu/libglut.so",
O_RDONLY) = 8
[pid  7943] stat("/usr/lib/gcc/x86_64-linux-gnu/4.6/../../../x86_64-linux-gnu/libGLU.so",
{st_mode=S_IFREG|0644, st_size=449168, ...}) = 0
[pid  7943] open("/usr/lib/gcc/x86_64-linux-gnu/4.6/../../../x86_64-linux-gnu/libGLU.so",
O_RDONLY) = 9
[pid  7943] stat("/usr/lib/gcc/x86_64-linux-gnu/4.6/../../../x86_64-linux-gnu/libGL.so",
{st_mode=S_IFREG|0644, st_size=390352, ...}) = 0
[pid  7943] open("/usr/lib/gcc/x86_64-linux-gnu/4.6/../../../x86_64-linux-gnu/libGL.so",
O_RDONLY) = 10
[pid  7943] open("/usr/lib/gcc/x86_64-linux-gnu/4.6/../../../x86_64-linux-gnu/libglut.so",
O_RDONLY) = 4
[pid  7943] open("/usr/lib/gcc/x86_64-linux-gnu/4.6/../../../x86_64-linux-gnu/libGL.so",
O_RDONLY) = 5
...

This happens because of there is a symbolic link in the standard
library search path for gcc, which is part of a Mesa package:

svenpanne@svenpanne:~$ ll /usr/lib/x86_64-linux-gnu/libGL.so
lrwxrwxrwx 1 root root 13 Jun 18 22:54
/usr/lib/x86_64-linux-gnu/libGL.so -> mesa/libGL.so
svenpanne@svenpanne:~$ dpkg -S /usr/lib/x86_64-linux-gnu/libGL.so
libgl1-mesa-dev: /usr/lib/x86_64-linux-gnu/libGL.so

Funnily enough, when you run the application later, it will use
NVIDIA's libGL.so, because the dynamic linker consults
/etc/ld.so.{cache,conf} and of course does not look into gcc's
library search path:

svenpanne@svenpanne:~/redbook$ ldd a.out | grep libGL
libGL.so.1 => /usr/lib/nvidia-current/libGL.so.1 (0x00007f7841b34000)

So in a nutshell: If you are explicit about your library dependencies,
things are inconsistent on Ubuntu. Because of this, GHCi loads Mesa's
libGL.so (found via 'gcc --print-names), which does not work with
NVIDIA drivers.

The question is: What to do about this? Adding /usr/lib/nvidia-current
to OpenGLRaw's library-dirs is wrong, because this will fail when you
e.g. temporarily switch to Mesa for OpenGL. I have the very strong
feeling that this is a Ubuntu bug: The link
'/usr/lib/x86_64-linux-gnu/libGL.so => mesa/libGL.so' is simply wrong
in the presence of NVIDIA drivers, and one should fix this by making
it point to /usr/lib/nvidia-current/libGL.so. A quick Google search
found that other people have similar problems:

https://answers.launchpad.net/ubuntu/+source/nvidia-graphics-drivers/+question/182181
http://techtidings.blogspot.de/2012/01/problem-with-libglso-on-64-bit-ubuntu.html
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=630527

while no attributes in shaders are not so common, with no uniforms the call of activeUniformsresults in a 'Stack Space Overflow'. This is because of an nasty GLuint overflow here:
https://github.com/haskell-opengl/OpenGL/blob/master/Graphics/Rendering/OpenGL/GL/Shaders/Variables.hs#L154

There is a lovely pipeline in OpenGL for working with 2d textures, etc. but the moment I need S3TC i need to go out to the raw bindings and throw away all the code I wrote using this package. =(

quoting appendix N.1 'New Features' from the OpenGL 3.0 spec:
"Half-float (16-bit) vertex array and pixel data (GL_NV_half_float and GL_ARB_half_float_pixel)."

edit: added the underscores

These can be passed to shaders.

I'm currently hacking around this by lying and claiming the field is an Index1, but it is very much a hack.

I haven't checked what other legal uniforms are missing.

The version of Haddock that's shipped with GHC 7.6.1 cannot process the newly released OpenGL 2.6.0.0 version because of the following error:

dist/build/tmp-1542/Graphics/Rendering/OpenGL/GL/QueryUtils/PName.hs:268:27:
    parse error on input `-- | Conversion from the casted value to the return value'
Haddock coverage:

Some functions and data types are from the outside placed in the 'wrong' module. For example what are Query objects doing in the PerFramgent module?
On the other side sometimes it is a decision between exporting stuff to the outside versus putting it in the right place. For example where should "transformFeedbackMode" be placed by its name it should be in the module TransformFeedback but it needs a programID or programVar, which would lead to exporting stuff that shouldn't be exposed to the outside.

I think that some solution should be found for this problem. Maybe in adding an extra namespace level or so?

I can't find binding for "Sampler Object" in the OpenGL package.

The following is in the OpenGLRaw package.
glGenSamplers :: GLsizei -> Ptr GLuint -> IO ()
glDeleteSamplers :: GLsizei -> Ptr GLuint -> IO ()
glIsSampler :: GLuint -> IO GLboolean

I think that the binding in the OpenGL package is implemented as instance of GeneratableObjectName.

The Uniform instance for TextureUnit implements the setter with uniform1 and the value stored in the TextureUnit as a GLuint. This results in a call to glUniform1ui which, for sampler uniforms, results in a GL_INVALID_OPERATION error.

As stated in the OpenGL 2.0 (and later) reference[1], samplers must be loaded by glUniform1i or glUniform1iv and loading with any other function will cause a GL_INVALID_OPERATION error.

Can be fixed by casting the GLuint to GLint in the Uniform instance or changing the GLuint to a GLint in TextureUnit (don't know what this would change elsewhere). Though, it might make sens to store it as GLuint anyway, because in glActiveTexture accepts a GLenum which in GL.h on my machine is typedefed to a unsigned int. The standard is a bit confusing here.

[1] See "Notes" section: http://www.opengl.org/sdk/docs/man2/xhtml/glUniform.xml

The corresponding constant is GL_LUMINANCE32F.

One- and two-dimensional layered texture targets
Not at a specific section, it's littered throughout OpenGL 3.0 spec section 3.9

Sometimes I want to use glUniform*, but the OpenGL UniformLocation type does not work with it. I have to unsafeCoerce it to the underlying GLint and use that. If the OpenGL API exposed all the uniform api, it wouldn't be an issue.

To be honest, I think OpenGL might be built too far above the raw bindings. Maybe it should just add type discipline to the GLRaw functions.

We need to do some clean up before we can get into the newest haskell platform:

• Get GLURaw and OpenGLRaw into the haskell platform
• Remove the top level StateVar (move into a better namespace)

Despite tesselation shaders exposed, important functions regarding them are missing from the bindings.

OpenGL 3.2 brings about several nice features, including the merging of geometry shaders into the official specification. It would be nice if the bindings supported this.

Implement conditional rendering,
OpenGL spec sec. 2.14

OpenGL 3.0 spec section 4.4

quoting appendix N.1 'New Features' from the OpenGL 3.0 spec:
"Per-color-attachment blend enables and color writemasks (GL_EXT_draw_buffers2)."

The new formats according to appendix N.1 'New Features' from the OpenGL 3.0 spec are:
Floating point color and depth
Non normalized integer color
Packed depth/stencil
Single and double channel

And one new compressed format:
RGTC

The build is still successful. The issue is that the FFI bindings use the stdcall convention, but this convention doesn't exist on x85-64 windows. The solution is to export the bindings with the ccall convention for 64-bit windows platforms.

Alternatively, these warnings could be suppressed because there is exactly one calling convention on this platform anyway.

I'm not sure which solution is better.

The withMappedBuffer helper function can be unsafe if the inner changes the VAO/VBO bindings and either forgets to change it back or gets interrupted by an exception.

withMappedBuffer could query the current buffer object at the beginning and restore it inside its finally block before calling unmapBuffer.

I'm not sure if there is a good reason for not doing this, but I thought I at least suggest this change here.

There are use cases where storing a Ptr a makes sense and the caller will clean up the memory when done with it. For example, if the caller has a ForeignPtr already you might see code like this:

withForeignPtr ptr $ \p -> do
  let pd = PixelData ... p
  ...

Here, the withForeignPtr will clean up p when done with it and pd should not escape (it is undefined outside of withForeignPtr).

I could also imagine a case where the PixelData is created outside of a withForeignPtr and the creator wants to associate a finalizer with the pointer stored inside. For this reason it may make sense to have a variant of PixelData that supports ForeignPtr.

It seems this one constant just got left out :)

framebufferTexture2D is typed as:

framebufferTexture2D :: FramebufferTarget -> FramebufferObjectAttachment -> TextureTarget2D -> TextureObject -> Level -> IO ()

But TextureCubeMapPositiveX is a TextureTargetCubeMapFace. Perhaps the type just needs to be relaxed to:

framebufferTexture2D :: TwoDimensionalTextureTarget tt => FramebufferTarget -> FramebufferObjectAttachment -> tt -> TextureObject -> Level -> IO ()

?

I'm trying to install OpenGL library. (ghc 7.4.1, Ubuntu Lucid)

But installation fails with

[54 of 82] Compiling Graphics.Rendering.OpenGL.GL.Evaluators ( Graphics/Rendering/OpenGL/GL/Evaluators.hs, dist/build/Graphics/Rendering/OpenGL/GL/Evaluators.o )

Graphics/Rendering/OpenGL/GL/Evaluators.hs:169:6:
Illegal datatype context (use -XDatatypeContexts): (ControlPoint c,
Domain d) =>
cabal: Error: some packages failed to install:
OpenGL-2.5.0.0 failed during the building phase. The exception was:
ExitFailure 1

quoting appendix N.1 'New Features' from the OpenGL 3.0 spec:
"Fine control over mapping buffer subranges into client space and flushing modified data (GL APPLE flush buffer range)."