@bjz if you want to return
Result<>and still load resources asynchronously, then you'd need a function to get the loaded result back. In @csherratt proposal, as I got it, there is no such function. Instead, the pipeline just avoids the use of the resource, and optionally (my proposal) reports the error back to the user via the designated channel.
And I think the Client struct can neatly manage the relevant channels
@photex @csherratt Awesome, at least we are one step closer to the consensus. The potential problem will arise if the user needs some data derived from the resource (mesh name?..). It could be solved, of course, by introducing another method like
client.really_give_me_the_mesh_info_now(). So far I'm trying to imagine the possible use-cases for that, if any...
@bjz I figured that since all creation routines will return the handle immediately, the reverse channel (from renderthread to user) will be free to use for the errors, i.e. no need for an additional channel, we just need to change the policy of using the the client and add a function to iterate current errors. All more or less trivial but blocked by the fact we don't have the proper handles yet. I'll create an issue shortly....
what will the active_value be used for?
@csherratt Thanks! the idea is to fully verify compatibility of the program with inputs/outputs (partially described here). This is not expensive by itself. The biggest question for me is what data structure to use for the shader parameters so that the program can query them quickly...
@csherratt
active_value is the current value of the parameter that GL program holds. It will be checked against the given value and updated accordingly if different.
The logic of binding is supposed to be the following: renderthread walks through all
ProgramMeta, and for each thing searches it among the given data (be it a mesh attribute or a shader parameter). Not sure if we can cache the match results, or if that's even needed... In my previous project I used to search by name (a boxed string), but we need something cheaper here.
@csherratt I'm kinda surprised (in a very positive way) to see you helping us out here, considering how big your snowmew is... Thanks!
My hope is that that is gfx-rs might offer a more portable backend for snowmew. The current render is not very flexible and needs to be reworked for OpenGL 3 hardware, which might be a rewrite of half the logic. So if gfx-rs can satisfy that goal I will be happy.
Plus snowmew goals are more research ordinated with the fringe benefit being a potential product.
kvark @kvark goal of working on gfx-rs is to have that sacred piece of code he can open up (when depressed, for example) with a cup of tee and enjoy reading it again and again...
@csherratt I liked your construction of the command buffers (from the presentation) with an idea to call
DrawIndirectMultiSomething for multiple objects at once. Not sure that all these workers benefit this much from walking the scene graph in parallel though... But fortunately, this is all very high-level from the gfx-rs perspective so could be done on top of it.
@kvark gfx-rs is your dream graphics pipeline that you one day hope OpenGL / DirectX will aspire to live up to?
Might be both, but frankly I don't want to look that far... I had a habit of imagining the future of my projects in past, and in most of the cases it didn't do me any good. Now I'm trying to look just in front of my nose: "ok, what needs to be done here? Ah, shaders meta is missing, resource management is missing, etc".
I don't believe GL/DX will ever aspire to gfx-rs, I'd rather have them go as low-level as possible so that gfx-rs can do stuff with less overhead.
I don't believe GL/DX will ever aspire to gfx-rs, I'd rather have them go as low-level as possible so that gfx-rs can do stuff with less overhead.
of course DX12 does not exist, but the promise of said features is probably enough to spell the death of Mantle.
@csherratt OpenGL also promised something low-level, IIRC. Problem with DX12 is that it's the least portable among those. I haven't had a chance to look at either Mantle or Metal (reading slowly...), but I got some solid experience with Gnm, and I expect it to be very similar.
@csherratt Have you looked at Mantle? Care to share what you think about it?
that being said, I think the path of having dozens of queues to feed the hardware pipeline is a good idea. At a high level there is quite a bit that can be done parallel.
At mozilla ready for the spinning trianglethon
I wonder if we can get gfx-rs working with cargo
sorry for being silent for a few days
@csherratt thanks for clarifying!
@csherratt I was curious as to what your intentions were - I was worried about duplicating some of your efforts
@kvark reading your patch now
but yeah - will be super excited to get some stuff done today