These are chat archives for bjz/gfx-rs

1st
Jul 2014
brendanzab @bjz is back after a day lost in the universe that is EFL
Dzmitry Malyshau
@kvark
Jul 01 2014 01:51
enlightment?
Brendan Zabarauskas
@brendanzab
Jul 01 2014 01:54
aye
we want to use it for servo
Dzmitry Malyshau
@kvark
Jul 01 2014 01:56
@bjz as the only backend? or just on-par with GTK?
Brendan Zabarauskas
@brendanzab
Jul 01 2014 01:56
for the context and keyboard/mouse stuff
also touch I think
not really for any widget stuff I don't think
brendanzab @bjz is reading #40
Dzmitry Malyshau
@kvark
Jul 01 2014 01:58
@bjz could you repro #89 on your side? just add UNIFORM_BLOCK_REFERENCED_BY_GEOMETRY_SHADER to the array in query_blocks, where the other definitions are (search for UNIFORM_BLOCK_REFERENCED_BY_VERTEX_SHADER)
Brendan Zabarauskas
@brendanzab
Jul 01 2014 01:59
well pub static UNIFORM_BLOCK_REFERENCED_BY_VERTEX_SHADER: GLenum = 0x8A44; is generating for me
as in, on the raw gl-rs build
not in gfx-rs
Dzmitry Malyshau
@kvark
Jul 01 2014 02:01
@bjz the question is whether or not UNIFORM_BLOCK_REFERENCED_BY_GEOMETRY_SHADER is generated. You are correct though that gfx-rs is not needed to repro it :)
Brendan Zabarauskas
@brendanzab
Jul 01 2014 02:02
what is the question?
Dzmitry Malyshau
@kvark
Jul 01 2014 02:03
check for UNIFORM_BLOCK_REFERENCED_BY_GEOMETRY_SHADER
Brendan Zabarauskas
@brendanzab
Jul 01 2014 02:03
what do you mean by 'check'?
Dzmitry Malyshau
@kvark
Jul 01 2014 02:04
Do you have it generated in raw gl-rs build? I do not, and that's what #89 is about. This definition is supposed to have the value 0x8A44
Brendan Zabarauskas
@brendanzab
Jul 01 2014 02:05
OOH, no I do not
Dzmitry Malyshau
@kvark
Jul 01 2014 02:05
yay!
Brendan Zabarauskas
@brendanzab
Jul 01 2014 02:05
we are getting somewhere
Dzmitry Malyshau
@kvark
Jul 01 2014 02:05
it took a while... :)
doesn't really matter for us that much, so no pressure
Brendan Zabarauskas
@brendanzab
Jul 01 2014 02:05
sorry!
yeah, but this is very odd.
Dzmitry Malyshau
@kvark
Jul 01 2014 02:06
np, I know you are busy
we all are...
Brendan Zabarauskas
@brendanzab
Jul 01 2014 02:06
something must be filtering it out...
or something...
Dzmitry Malyshau
@kvark
Jul 01 2014 02:14
@bjz is glfw out of date? my PR fails on Travis, but updating glfw-rs gets me nothing
Brendan Zabarauskas
@brendanzab
Jul 01 2014 02:19
ok, lemme update glfw
ugh, so annoying
Dzmitry Malyshau
@kvark
Jul 01 2014 02:23
thanks!
Brendan Zabarauskas
@brendanzab
Jul 01 2014 02:33
@kvark bjz/glfw-rs#184
ooh!
\o/
kvark @kvark was watching your every step
Brendan Zabarauskas
@brendanzab
Jul 01 2014 02:34
Dzmitry Malyshau
@kvark
Jul 01 2014 03:00
@bjz I think that's it for me for today. Please have a look at #40 when you have a chance. Perhaps, @csherratt could find it interesting as well? ;) Basically, only two things are left on my list:
  1. uniform block binding
  2. testing the whole thing
Coraline Sherratt
@removed~csherratt
Jul 01 2014 03:16
We might want to look at storage of the UniformValue. I think it is 70 bytes.
Dzmitry Malyshau
@kvark
Jul 01 2014 03:18
@csherratt yeah, that sucks. A radical proposal: only allow matrices (and arrays) in uniform blocks? Without matrix variant, it should be much tiner
Dzmitry Malyshau
@kvark
Jul 01 2014 03:23
even though, it's going to screw up a lot of folks who just want to do it by tutorial and declare model/view/projection matrices...
It is 68 as is, and just 20 without the matrix variant
kvark @kvark went to sleep
Coraline Sherratt
@removed~csherratt
Jul 01 2014 03:25
ok
I think if that is a performance issue, we are in good shape.
Brendan Zabarauskas
@brendanzab
Jul 01 2014 04:21
@csherratt o/
brendanzab @bjz heads home
Dzmitry Malyshau
@kvark
Jul 01 2014 07:58
@csherratt so your concern is the safety (in a broad term) of variable handles? Here is what can be misused:
  1. A variable is used with the wrong environment. This is a major concern that doesn't have a solution yet. I wonder if we can somehow randomize variable handle generation and still maintain indexing-line performance.
  2. A variable is modified. We can protect against this by enclosing the index as the only private field in the struct, i.e. pub struct UniformVar(u8) instead of pub type UniformVar = u8
  3. A wrong type is used for the variable assignment. I can only see it happening if, for example, we added a uniform as an int, and then tried to reassign (via set_uniform) a float. We can solve it by verifying (perhaps, in debug only) that reassigning a uniform doesn't change it's sub-type.
About UniformValue size... what do you think if we switch the matrix (and potential arrays) to boxed? It does make sense for arrays, and would minimize matrix copying costs.
Dzmitry Malyshau
@kvark
Jul 01 2014 15:22
@bjz Rust doesn't allow me to have Box<[[f32, ..4], ..4]> :(
Dzmitry Malyshau
@kvark
Jul 01 2014 15:28
@csherratt What if we get a pseudo-random number in the envir::Storage private field, then embed it into every variable that is generated by it. Assuming they are unique, we can debug_assert! on the attempt to use variables from different environments. I can see std::time::get_time, and we can start with that, then switch to something more reliable, if needed
Brendan Zabarauskas
@brendanzab
Jul 01 2014 15:35
@kvark waaat
Compiles on playpen.
type T = Box<[[int, ..3], ..3]>;
struct U { u: Box<[[int, ..3], ..3]> }
fn foo(_: T) {}
fn bar(_: Box<[[int, ..3], ..3]>) {}
Dzmitry Malyshau
@kvark
Jul 01 2014 15:49
@bjz sure, now please try to actually construct it
let t = box [[0, ..3], ..3];
error: obsolete syntax: ~[T] is no longer a type
Brendan Zabarauskas
@brendanzab
Jul 01 2014 16:07
HAHA
let x: T = box () ([[1, 2, 3], [1, 2, 3], [1, 2, 3]]);
Dzmitry Malyshau
@kvark
Jul 01 2014 16:08
oh, that's tricky
Brendan Zabarauskas
@brendanzab
Jul 01 2014 16:08
This is because of the hacky way that ~[] was removed
it will be fixed
brendanzab @bjz was with @pcwalton when he killed it
Dzmitry Malyshau
@kvark
Jul 01 2014 16:09
ok, thanks for the explanation! Do you know how to clone such a box (Box<[[int, ..4], ..4]>) without enumerating all the fields?
Brendan Zabarauskas
@brendanzab
Jul 01 2014 16:09
ohai @photex and @csherratt !
@kvark not sure you can :(
stupid fixed-length vecs
ask on #rust :P
Chip Collier
@photex
Jul 01 2014 16:13
how do people feel about perhaps moving away from submodules and getting started with Cargo
these things are a pain for lots of frequently updated dependencies
?
Dzmitry Malyshau
@kvark
Jul 01 2014 16:16
@photex I got no opinion here, since haven't actually used cargo. Dependencies seem manageable.
Brendan Zabarauskas
@brendanzab
Jul 01 2014 16:17
yeah, I haven't figured out how to use cargo with a library yet
Chip Collier
@photex
Jul 01 2014 16:17
hrm, no worries then
I'll just get used to always having some odd status reported by git
"new commits" etc
Brendan Zabarauskas
@brendanzab
Jul 01 2014 16:19
yeah :S
please give @kvark your feedback on the latest PRs! :)
brendanzab @bjz has to get back to EFL
Brendan Zabarauskas
@brendanzab
Jul 01 2014 16:21
yeek
Chip Collier
@photex
Jul 01 2014 16:22
yes, @kvark is ON A ROLL!
Dzmitry Malyshau
@kvark
Jul 01 2014 16:26
@photex I'm happy that the old nasty problem (of passing shader parameters safely and effectively) is finally tackled!
@csherratt BTW, I've implemented all the safety stuff (pushed already, see TODO in #40)
Chip Collier
@photex
Jul 01 2014 16:26
:clap:
Dzmitry Malyshau
@kvark
Jul 01 2014 16:28
@photex please have a look at the code, so I can fix stuff before getting @bjz angry with a need to clean up after me ;)
Chip Collier
@photex
Jul 01 2014 16:28
you got it. I'm updating rust real quick
also, USA vs Belgium is during my lunch
trying to do something productive before the day escapes
Brendan Zabarauskas
@brendanzab
Jul 01 2014 16:29
haha
@kvark no worries - I am just the janitor
Dzmitry Malyshau
@kvark
Jul 01 2014 16:30
@bjz To my defense, this PR has zero warnings (and old are cleaned up as well)
Brendan Zabarauskas
@brendanzab
Jul 01 2014 16:30
^_^
Dzmitry Malyshau
@kvark
Jul 01 2014 16:31
@bjz Dunno how we can transfer the uniform block structure from user to the device... Hide it behind a trait that has get_address() and get_size()?
Coraline Sherratt
@removed~csherratt
Jul 01 2014 16:31
@kvark if we box the model matrix won't that make hundreds if not thousands of box allocations per frame?
then again the message itself is allocated.
Dzmitry Malyshau
@kvark
Jul 01 2014 16:33
@csherratt My thought was to encourage matrices and arrays only in uniform blocks. Thus, people will still be able to pass them as uniforms, but they'll pay a little for the allocation (less copying though)
@csherratt wait, what message is allocated?..
Brendan Zabarauskas
@brendanzab
Jul 01 2014 16:34
the message is allocated?
Chip Collier
@photex
Jul 01 2014 16:34
is this the Clone trait implementation you're referring to @csherratt ?
Coraline Sherratt
@removed~csherratt
Jul 01 2014 16:34
send() recv() can allocate memory. It is implemented as a list not a ring buffer. They keep a small pool of reused messages to avoid overhead. ... my knowledge could be out of date since this has changed at least twice in the last year.
sorry not recv() just send()
let me just check
Dzmitry Malyshau
@kvark
Jul 01 2014 16:36
@csherratt Can we leave that to Rust folks to optimize?
Coraline Sherratt
@removed~csherratt
Jul 01 2014 16:36
yes
yay~ good to be wrong
it is now implemented as a ring buffer.
Chip Collier
@photex
Jul 01 2014 16:41
@kvark could we have parameter names match their types a bit closer:
storage: &envir::Storage, shortcut: &envir::Shortcut
and so on
Chip Collier
@photex
Jul 01 2014 16:47
@kvark why the term "Block" instead of Buffer?
I don't understand the distinction yet
photex @photex needs to construct a concept map ;)
Dzmitry Malyshau
@kvark
Jul 01 2014 16:49
@photex A uniform block term has the shader program in the context, while uniform buffer is just a junk of GPU memory.
at least, that's how I reason about it...
I mean, a block is a program parameter, while a buffer is the value. That seems clearer
Chip Collier
@photex
Jul 01 2014 16:49
OH
that's the str
ok
so this is input to a program
Dzmitry Malyshau
@kvark
Jul 01 2014 16:50
yeah, program inputs are nicely described in ProgramMeta. See the blocks there
Chip Collier
@photex
Jul 01 2014 16:50
all clear now
Coraline Sherratt
@removed~csherratt
Jul 01 2014 16:50
it's what they are called in glsl. a block is backed by a buffer.ls
eep ...
Dzmitry Malyshau
@kvark
Jul 01 2014 16:50
I've probably screwed up the naming myself in some places
Chip Collier
@photex
Jul 01 2014 16:51
I'm kind of following this stream of consciousness style at the moment
Dzmitry Malyshau
@kvark
Jul 01 2014 17:30
@bjz @photex @csherratt I'm done for now. Life calls ;)
#40 is ready. Uniforms semantic verification is the latest shining feature I got.
Brendan Zabarauskas
@brendanzab
Jul 01 2014 17:39
@kvark As I said on #40, sorry for having trouble keeping up - you are crazy productive!
Chip Collier
@photex
Jul 01 2014 17:40
yeah cheers @kvark
sooo glfw... not compatible with the version shipping with Fedora17
Brendan Zabarauskas
@brendanzab
Jul 01 2014 17:40
:(
Chip Collier
@photex
Jul 01 2014 17:40
which is still glfw 3, but I guess they arae incompatible between micro versions! :)
Brendan Zabarauskas
@brendanzab
Jul 01 2014 17:40
ping on #glfw?
Chip Collier
@photex
Jul 01 2014 17:40
awesome library
glfw.rs:(.text._ZN6Window16set_should_close20hc68c4f6342def0125Se4v0.1E+0x8): undefined reference to `glfwSetWindowShouldClose'
glfw-rs seems to build just fine though
Brendan Zabarauskas
@brendanzab
Jul 01 2014 17:46
they might have altered the API
what git tag are you pulling from
maybe we should add that to the README
check out travis
Chip Collier
@photex
Jul 01 2014 18:05
Fedora17 is an older release
I'm just using the glfw available in the yum repo
libglfw.so.3
SDL2 also seems to be adding or altering apis in micro-releases
semantic version is not a thing for libraries of this variety I suppose
Coraline Sherratt
@removed~csherratt
Jul 01 2014 19:27
Oops. my one line re-export of IndexSlice caused a conflict.
@bjz any problem with #40?
Coraline Sherratt
@removed~csherratt
Jul 01 2014 19:35
I have it merged locally and ready to commit if you do not.
This message was deleted
Brendan Zabarauskas
@brendanzab
Jul 01 2014 20:24
@csherratt no problem
Coraline Sherratt
@removed~csherratt
Jul 01 2014 21:02
so, snowmew is partially working on gfx now https://www.youtube.com/watch?v=hAWM8_HXc7U&feature=youtu.be
Dzmitry Malyshau
@kvark
Jul 01 2014 21:02
Thanks everyone for looking into #40! Please keep an eye on our major architectural issues (#9, #21, #38). The further we go, the more it hurts us to keep them unresolved.
Coraline Sherratt
@removed~csherratt
Jul 01 2014 21:03
The depth buffer is not :(
Dzmitry Malyshau
@kvark
Jul 01 2014 21:04
depth buffer is not working?
Coraline Sherratt
@removed~csherratt
Jul 01 2014 21:05
it looks like it is disabled based on the fact the green one is in front.
Dzmitry Malyshau
@kvark
Jul 01 2014 21:06
@csherratt you are using default framebuffer?
Coraline Sherratt
@removed~csherratt
Jul 01 2014 21:06
This is how it looks with the primary render.
that is a good point...
    glfw.window_hint(glfw::OpenglProfile(glfw::OpenGlCoreProfile));
    glfw.window_hint(glfw::OpenglForwardCompat(true));
    glfw.window_hint(glfw::Visible(false));
    glfw.window_hint(glfw::DepthBits(24));
    glfw.window_hint(glfw::StencilBits(8));
    glfw.window_hint(glfw::Decorated(false));
at one point I disabled the Primary depth buffer, but that no longer looks like the case.
Dzmitry Malyshau
@kvark
Jul 01 2014 21:08
and how/where do you set depth test/write?
Coraline Sherratt
@removed~csherratt
Jul 01 2014 21:10
I don't. So It's not unexpected. I didn't see a way to set that with gfx yet.
Dzmitry Malyshau
@kvark
Jul 01 2014 21:10
@csherratt gfx-rs doesn't have this yet, sorry
it is less barely 2 weeks old...
Coraline Sherratt
@removed~csherratt
Jul 01 2014 21:12
it's early days. I'm amazed this much is working.
Dzmitry Malyshau
@kvark
Jul 01 2014 21:15
My old rasterizer state could be helpful if you want to start hacking on it. I imagine you'd rather work on snowmew, but I hope to be wrong :)
Coraline Sherratt
@removed~csherratt
Jul 01 2014 21:15
I'm liking the bindless nature of the api so far.
Dzmitry Malyshau
@kvark
Jul 01 2014 21:50
@csherratt What do you think about removing device::Client entirely and moving the server implementation to be platform-dependent? That would eliminate the whole extra 2 layers of indirection.
Coraline Sherratt
@removed~csherratt
Jul 01 2014 21:53
It makes sense to me. Even just getting that quick demo working on snowmew I kept getting confused at which Client the api providers me and which one is internal to the system.
Plus, that will be like 3 context switches to get a single call out to the gpu. (Client -> Server, Client-> Server, OpenGL -> OpenGl Driver) vs (Client -> Server, OpenGL -> OpenGL Driver).
I think the larger question might be what is the long term goals for GFX. Is GFX a nice set of wrappers that provide some degree of platform abstraction? Or is GFX an API that not only simplifies things for the user, but it can also perform optimizations via batch aggregation, and call reordering.
Coraline Sherratt
@removed~csherratt
Jul 01 2014 21:59
having an intermediate server that can do optimizations on the calls being sent might be helpful. But it could also be pawned off onto the client's thread.
Dzmitry Malyshau
@kvark
Jul 01 2014 22:06
@csherratt Thanks for your input. I'm just frustrated a bit by the amount of layers we've got. Please see #9 if you haven't already. Removing device::Client and forcing the platform-dependent part to implement device::Server will help a lot. We can also move the device task into its own crate (#38).
As for the batching and optimization - I believe this should be done by our render task. I wish we could simplify it as well in regards to layers...
Dzmitry Malyshau
@kvark
Jul 01 2014 22:33
@bjz let me know what you think about #48 please, before I start (tomorrow night, most likely) ;)