These are chat archives for bjz/gfx-rs

6th
Jul 2014
Marvin Löbel
@Kimundi
Jul 06 2014 00:18
I think all concerns of #72 have been resolved, right? Should I squash it?
Brendan Zabarauskas
@brendanzab
Jul 06 2014 00:18
sounds good! then I will merge
Marvin Löbel
@Kimundi
Jul 06 2014 00:19
Okay, done
Corey Richardson
@cmr
Jul 06 2014 02:03
Translations certainly belongs in its own crate
But translation isn't necessarily the only thing we need to do
Maybe for gfx-rs all it needs is a way to tell the applicatoin what shader language it should use
Coraline Sherratt
@removed~csherratt
Jul 06 2014 02:16
I don't think we need to do the translation. That is totally the domain of using a 3rd party library.
Corey Richardson
@cmr
Jul 06 2014 02:17
Yeah
Dzmitry Malyshau
@kvark
Jul 06 2014 03:33
@Kimundi I'm actually getting "[gfx-rs] No supported GLSL shader provided!" :(
Brendan Zabarauskas
@brendanzab
Jul 06 2014 03:34
@kvark should we roll back?
brendanzab @bjz tests
Dzmitry Malyshau
@kvark
Jul 06 2014 03:34
I'll try to fix it here
Brendan Zabarauskas
@brendanzab
Jul 06 2014 03:35
I get the same!
Would be useful to print out the returned string too
Dzmitry Malyshau
@kvark
Jul 06 2014 03:35
lesson to self: test risky changes before letting them in
Brendan Zabarauskas
@brendanzab
Jul 06 2014 03:37
lol! WARN:device::gl::shade: OpenGL driver reported unknown GLSL language version: 4.10
:P
Dzmitry Malyshau
@kvark
Jul 06 2014 03:37
oops
Brendan Zabarauskas
@brendanzab
Jul 06 2014 03:37
haha
@kvark btw: warn!("OpenGL driver reported unknown GLSL language version: {}", c_s_b);
be sure to put that in
Dzmitry Malyshau
@kvark
Jul 06 2014 03:39
perhaps you got the fix?..
Brendan Zabarauskas
@brendanzab
Jul 06 2014 03:39
we might need to re-think this :/
This design is actually quite brittle...
Dzmitry Malyshau
@kvark
Jul 06 2014 03:41
hmm... I wonder if we should extract the numbers and compare numerically
Brendan Zabarauskas
@brendanzab
Jul 06 2014 03:41
yeah
using a lexical ordering
I dunno...
btw, is the string returned defined by the spec?
Dzmitry Malyshau
@kvark
Jul 06 2014 03:44
yes: "OpenGL<space>ES<space>GLSL<space>ES<space><version number><space><vendor-specific information>"
Brendan Zabarauskas
@brendanzab
Jul 06 2014 03:44

The GL_VERSION and GL_SHADING_LANGUAGE_VERSION strings begin with a version number. The version number uses one of these forms:

major_number.minor_number major_number.minor_number.release_number

Vendor-specific information may follow the version number. Its format depends on the implementation, but a space always separates the version number and the vendor-specific information.

ahh yep
Dzmitry Malyshau
@kvark
Jul 06 2014 03:45
@bjz I'm also scared of std::c_str::CString::new
Brendan Zabarauskas
@brendanzab
Jul 06 2014 03:48
@kvark I'm wondering if we should roll back and try to get a proper capability infrastructure up before trying to do this shader version detection stuff
:(
Dzmitry Malyshau
@kvark
Jul 06 2014 03:49
@bjz I'd rather patch what we have. Rolling back is a bit of a hit for @Kimundi
Brendan Zabarauskas
@brendanzab
Jul 06 2014 03:49
mmk
Dzmitry Malyshau
@kvark
Jul 06 2014 03:52
r? #73
Dzmitry Malyshau
@kvark
Jul 06 2014 03:57
@bjz Also, #74 takes us one step closer to the terrain sample
Dzmitry Malyshau
@kvark
Jul 06 2014 04:03
@Kimundi with #74 you can create arbitrary meshes (any number of attributes of any types) using convenient Constructor
Brendan Zabarauskas
@brendanzab
Jul 06 2014 04:05
Awesome, #73 fixes it for me
Dzmitry Malyshau
@kvark
Jul 06 2014 04:05

in the triangle example:

gfx::Constructor::new(buf).
                add("a_Pos", 2, "f32").
                complete(3)

I believe that's as close as we can get without some heavy macros magic. And even with it we will not be able to extract all the info from the types... So we might be using this solution for quite a while.

@bjz If @Kimundi will be unavailable tomorrow, I'll take care of GLSL versioning. I fully realize how temporal is the current situation. Meanwhile, have a look at #74
Brendan Zabarauskas
@brendanzab
Jul 06 2014 04:07
@kvark gotta head out for abit, but I will check it out later
Dzmitry Malyshau
@kvark
Jul 06 2014 04:07
sure, I'm off too
Brendan Zabarauskas
@brendanzab
Jul 06 2014 04:08
been playing around with ideas for more ergonomic construction of envrionments too
Dzmitry Malyshau
@kvark
Jul 06 2014 04:12
@bjz oh nice! keep in touch about that please, I was going to get my hands on the Environment right after Mesh, which I consider semi-completed.
The only issue that bothers me about meshes is that we can't accept a generic data array for the buffer construction (that hurts uniform buffers even more)...
Corey Richardson
@cmr
Jul 06 2014 04:13
I have some ideas on how to make that nicer.
It was for hgl
It involves a VertexLayout trait that you implement for your type.
it would return a vec of essentially what you pass to the add method in your Mesh
the nice thing is you can then add a fancy macro for describing vertex layout
that does all the correct struct packing etc
and have it all generated at compile-time
(there would probably be a StaticVertexLayout too, that returns a &'static [(&'static str, uint, &'static str)], to avoid the allocation)
Corey Richardson
@cmr
Jul 06 2014 04:19
Oh right, can just use the MaybeOwned pattern, don't need an extra triat ^_^
so, when is it socially acceptable for me to start demanding documentation ;)
Brendan Zabarauskas
@brendanzab
Jul 06 2014 05:13
@cmr how can we prevent that ugly sending on a closed channel error?
Corey Richardson
@cmr
Jul 06 2014 05:14
@bjz where, specifically?
Brendan Zabarauskas
@brendanzab
Jul 06 2014 05:15
the triangle example
when it closes
Corey Richardson
@cmr
Jul 06 2014 05:16
have to use send_opt
I'm super tired, going to bed
Brendan Zabarauskas
@brendanzab
Jul 06 2014 05:16
o/
Brendan Zabarauskas
@brendanzab
Jul 06 2014 06:20
Fixed it!
Marvin Löbel
@Kimundi
Jul 06 2014 10:45
@kvark: The vertex attribute stuff looks nice
Marvin Löbel
@Kimundi
Jul 06 2014 11:02
And yeah the GLSL stuff does not seem to be foolproof yet. Apparently it would be more robust to change over to querying the OpenGL version directly, or at least make the current detection stuff ignore any vendor specific additions to the string.
Dzmitry Malyshau
@kvark
Jul 06 2014 13:15
@Kimundi Can you make it numberic? Instead of GLSL150 constant the user can just pass 150, or GLSL(150)
@cmr Please express your ideas on VertexLayout in #39 . Note that if we have a generic version of create_buffer and update_buffer, we can totally cleanup all its current versions (create_vertex_buffer, create_index_buffer, create_uniform_buffer)
Marvin Löbel
@Kimundi
Jul 06 2014 13:34
kvark: If I find time today I can work on that.
Do you mean the internal enum, or the macro?
Dzmitry Malyshau
@kvark
Jul 06 2014 13:39
@Kimundi I'm on it now (hope you don't mind?). Will let you know if I'm stuch or done
@cmr You've got something about Environment as well?
Marvin Löbel
@Kimundi
Jul 06 2014 13:45
No, thats fine I wouldn't be able to work on it for a few hours anyway
Dzmitry Malyshau
@kvark
Jul 06 2014 13:52
Ok, cool, I've got the window of opportunity then ;)
Dzmitry Malyshau
@kvark
Jul 06 2014 15:06
@Kimundi ok, done - see #77
@csherratt please have a look at #74 . @bjz @cmr see #77 as well.
Dzmitry Malyshau
@kvark
Jul 06 2014 15:38
@bjz so what happens now when you close the window after #76?
Dzmitry Malyshau
@kvark
Jul 06 2014 16:03
Ok, I'll answer it myself. Application calls 'device.close' - a new method, which sends RequestClose signal to the renderer and waits for it to answer. Renderer breaks its loop and finishes the task.
Brendan Zabarauskas
@brendanzab
Jul 06 2014 16:31
Sorry - I have to go now - catching up with friends in Golden Gate Park.
I will have to do more commenting on that close thingy
Marvin Löbel
@Kimundi
Jul 06 2014 18:09
@kvark: Can comfirm that#77
works
(If I comment out VAOs and Uniform blocks as usual)
Dzmitry Malyshau
@kvark
Jul 06 2014 18:50
@Kimundi awesome, thanks!
Marvin Löbel
@Kimundi
Jul 06 2014 18:51
@kvark I see shaders are now classified by something called "shader model" - is that the direct3d system?
Dzmitry Malyshau
@kvark
Jul 06 2014 18:56
yeah. It just needs to be anything platform-agnostic on the generic-device level
Marvin Löbel
@Kimundi
Jul 06 2014 18:57
Okay, just wanted to confirm :)
Dzmitry Malyshau
@kvark
Jul 06 2014 18:57
if you know a better system, I'm all for it. DX shader model is what I typically see in books, blogs, and, well, our companies code ;)
Marvin Löbel
@Kimundi
Jul 06 2014 18:59
heh, I'll have to pass there ;)
Corey Richardson
@cmr
Jul 06 2014 18:59
D3D's shader system is so much more sane than GL's
@kvark What is the Environment?
I will leave some notes on #39 later
Dzmitry Malyshau
@kvark
Jul 06 2014 19:01
@cmr Environment was intended to be a storage for uniform shader parameters (three groups of them: blocks, bare uniforms, and textures). In the same way a Mesh is a storage for shader inputs (vertex attributes)...
@cmr when a program is activated, it looks for the attributes it needs in the Mesh and for the uniforms in Environment and binds them. This is supposed to be cached.
@cmr this is one of the problems with passing Mesh and Environment by reference though - we always need to compute some hash and check if we processed some shader with them already.
Marvin Löbel
@Kimundi
Jul 06 2014 19:16
@kvark: So, if I wanted to work on the VAO and uniform block problem, how would I best handle it? Add both to Capabilities, and only enable if supported?
Maybe substitute the ARB extension for VAO instead
Dzmitry Malyshau
@kvark
Jul 06 2014 19:22
@Kimundi Yes, I believe wiring this up via capabilities would be great, if you can do this. Not sure, for example, how would you check that uniform blocks are supported.
I'm leaving for a couple of hours
Marvin Löbel
@Kimundi
Jul 06 2014 19:28
@kvark Could just check what OpenGL version is supported at all I guess
Corey Richardson
@cmr
Jul 06 2014 19:29
Doing checks based on GL version is undesirable IMO
even if the version is 2.1 a lot of extensions are usually available
Marvin Löbel
@Kimundi
Jul 06 2014 19:46
@cmr Sure, I meant as a fallback if thats not possible for some reason.
Anyway
Marvin Löbel
@Kimundi
Jul 06 2014 21:32
Hm, I have a feeling we might want two different kinds of Capability: A user facing, cross-device one, which is what #77 added, and a private device specific one for stuff like the OGL 2.1 compat features
Dzmitry Malyshau
@kvark
Jul 06 2014 21:38
@Kimundi Why can't the latter one be a part of the public one?
User may want to change its behavior if, to say, uniform blocks are not supported
Marvin Löbel
@Kimundi
Jul 06 2014 21:40
Well, I'm not sure, but I could imagine things like "If OGL 3.30 is supported, use a official feature of it. else, emulate the feature with custom code"
The user might want to know about anyway though...
Dzmitry Malyshau
@kvark
Jul 06 2014 21:43
yeah, there is no harm in providing the user with more info in the existing Capabilities thing, but the problem is that it's cross-platform... Dunno what to do with API-specific caps, but since they are not exposed, particular back-ends may keep them internally in an unrestricted manner.
Marvin Löbel
@Kimundi
Jul 06 2014 21:44
Yeah, thats what I meant basically
I guess I also lack to much knowledge for now... I don't know if something like unifom blocks is a OGL-specific thing, or a concept that exist in general cross platform.
Dzmitry Malyshau
@kvark
Jul 06 2014 21:45
it's a general concept, fortunately ;)
Marvin Löbel
@Kimundi
Jul 06 2014 21:45
Anyway, is it okay if I just add two boolean flags for the two features that break on my pc to the Capability struct for now? Can always refactor them to be more clear later on.
Heh, okay
Dzmitry Malyshau
@kvark
Jul 06 2014 21:46
@Kimundi remind me. Your flags are the uniform blocks and VAO? I suppose we can have them in Capabilities, sure.
Marvin Löbel
@Kimundi
Jul 06 2014 21:46
Yeah, those two
Okay
Marvin Löbel
@Kimundi
Jul 06 2014 22:43
@kvark Heh, I just realized that VAO are supported by my hardware.
Corey Richardson
@cmr
Jul 06 2014 22:43
I said that, didn't I? :P
Since you're using a recent mesa, you support most extensions.
Marvin Löbel
@Kimundi
Jul 06 2014 22:43
Yeah you said that, but I didn't understood ;D
Corey Richardson
@cmr
Jul 06 2014 22:44
Ah
My bad then
VAOs in particular are really just a driver implementation detail -- even if the hardware can't have an advantage with them, the driver can simulate them.
Marvin Löbel
@Kimundi
Jul 06 2014 22:45
But now that I am actually tracing what function calls belonged to which extension, I realized "Wait... I support this!"
Makes sense
Now I wonder if I should actually keep it in the capability struct
But I guess it would set a good precedent if every extension gfx uses is explicitly being checked right?
Corey Richardson
@cmr
Jul 06 2014 22:47
I think every GL feature we use beyond 2.0 should be a capability
right
Marvin Löbel
@Kimundi
Jul 06 2014 22:48
Okay, how should the device react if the renderer wants to use a feature it doesn't support? Send back a error result (or equivalent)?
Dzmitry Malyshau
@kvark
Jul 06 2014 22:48
@cmr r/merge? #77
@Kimundi you can error! and ignore it for now, I suppose
Marvin Löbel
@Kimundi
Jul 06 2014 22:50
Alright
Dzmitry Malyshau
@kvark
Jul 06 2014 22:50
once we make device and render communicate asynchronously, we'll just add it as an error message
Corey Richardson
@cmr
Jul 06 2014 22:50
@kvark #77 needs a rebase
also I think most features can be emulated if not present
Dzmitry Malyshau
@kvark
Jul 06 2014 23:01
@cmr rebased
thanks
Dzmitry Malyshau
@kvark
Jul 06 2014 23:08
#74 is also rebased now
@cmr is a magician
Marvin Löbel
@Kimundi
Jul 06 2014 23:49
Okay, opened a PR that will make the gfx example runnable without modification on my machine
And I'm off to sleep now, good night.
Dzmitry Malyshau
@kvark
Jul 06 2014 23:50
@Kimundi thanks for your work! g'night!