Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • Jan 21 15:46
    SimonWoodburyForget closed #3129
  • Jan 21 15:46
    SimonWoodburyForget commented #3129
  • Jan 20 19:58
    parasyte edited #3128
  • Jan 20 15:05
    kvark commented #3128
  • Jan 20 14:40
    kvark labeled #3130
  • Jan 20 14:40
    kvark labeled #3130
  • Jan 20 14:40
    kvark labeled #3130
  • Jan 20 14:40
    kvark labeled #3130
  • Jan 20 14:40
    kvark labeled #3130
  • Jan 20 14:40
    kvark opened #3130
  • Jan 20 10:13
    pluth commented #3128
  • Jan 20 09:59
    pluth commented #3128
  • Jan 20 09:59
    pluth commented #3128
  • Jan 20 09:52
    pluth commented #3128
  • Jan 20 07:41
    krogovin commented #2960
  • Jan 19 22:24
    kvark commented #3129
  • Jan 19 22:16
    SimonWoodburyForget commented #3129
  • Jan 19 21:43
    kvark labeled #3129
  • Jan 19 21:43
    kvark labeled #3129
  • Jan 19 21:42
    kvark commented #3129
Coraline Sherratt
@removed~csherratt
@kvark If you let the client enumerate the handle you can avoid the round trip. CreateFoo(unique number, args). Then later when you want to use the handle, UseFoo(same unique handle, args). Since it is in a FIFO the server will see the CreateFoo before the UseFoo and it should work.
The creation of the unique number would need to be transparent to the client. It's just a implementation detail.
Coraline Sherratt
@removed~csherratt
If the handle in this case was actually just an pointer, the server would not even need to look up anything.
Dzmitry Malyshau
@kvark
@csherratt What exactly do you mean by "client enumerate the handle"? Overall, I kinda like this solution. There would be no need to wait synchronously for the user. From his perspective, once something is queried for creation, it exists. Our Client would have to make sure everything is loaded by the time it is used. A big question here is whether this checks are going to be any heavy for us to bear (because most of the time Use function is called the resource is already there).
Coraline Sherratt
@removed~csherratt
What is the content of the handle exactly?
Dzmitry Malyshau
@kvark
So far the handle is represented as (id, generation) pair (see @photex data.rs). Not sure if we are going to add some custom info to it later on the way (depending on the type)
Coraline Sherratt
@removed~csherratt
hmm
So when I meant by enumerate the handle is that the client figures out the Id of the handle, it does not have to wait for the server to figure it out.
Not sure of the generation field...
The id can just be bumping an atomic variable.
Dzmitry Malyshau
@kvark
@csherratt I don't think the figuring out of the ID takes long enough to defer it :) We are talking about deferring program linking, buffer and texture loading, and such. So the user may call Create() and get the unique handle back from Client.
Coraline Sherratt
@removed~csherratt
Ah that makes more sense.
So if you are doing an async program linking, how do we know if it failed or not?
Dzmitry Malyshau
@kvark
@csherratt Good question. Here comes the proposal to solve it: error channel. It's a simple one-side channel that will be used to report errors back to the user. The errors are gonna be defined as enum Error {}, and the user is going to be responsible for checking those and make arrangements accordingly. Does that sound good to @bjz @photex ?
Coraline Sherratt
@removed~csherratt
Is the pipeline stall caused by the user checking an issue worth fixing?
*use waiting on the error result
Dzmitry Malyshau
@kvark
@csherratt I don't think there is going to be any stall at all. The device will catch the error, report somehow to the renderthread, that one will send the error message to the channel that user receives on. User is free to do it at will, but the pipeline will continue to function and will just ignore all the calls that require broken resources.
Coraline Sherratt
@removed~csherratt
That makes sense. So there is no harm telling the pipeline to use a resource that is not fully linked yet, worst case all commands after the compilation will be discarded and the user will get a black frame buffer back.
Dzmitry Malyshau
@kvark
@csherratt That sounds interesting but it's not exactly what I meant. I thought the Client will make sure that any resource that is needed for a call is loaded. So the call will be ignored only if some of the dependencies failed (there but they have finished loading regardless).
Brendan Zabarauskas
@brendanzab
So do you think it would be too costly to return a Result<> for each fallible message?
Dzmitry Malyshau
@kvark
@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.
Chip Collier
@photex
I'm feeling positive about the designated channel for errors, and simply ignoring requests for "invalid" resources.
And I think the Client struct can neatly manage the relevant channels
Coraline Sherratt
@removed~csherratt
I like the idea of an async error channel.
Dzmitry Malyshau
@kvark
@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...
Coraline Sherratt
@removed~csherratt
A concrete example would be good.
Dzmitry Malyshau
@kvark
@csherratt I recall one example from my experience. Had a number of different skinning shaders: one for quaternion-provided geometry, one for tangent/bitangent, one for the geometry that only got normals. Was choosing the proper shader based on what mesh carried.
Brendan Zabarauskas
@brendanzab
Ok, if you guys are convinced an async error handling strategy is best, lets do it! Probably makes more sense in a game dev context.
Dzmitry Malyshau
@kvark
@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....
Dzmitry Malyshau
@kvark
Created #22. @photex Please feel free to grab and assign it on yourself. I didn't do it in case you had other stuff to do.
Dzmitry Malyshau
@kvark
@bjz are you alright there?
Dzmitry Malyshau
@kvark
@photex @cmr @csherratt A sneak peak into my vision of our low-level shader information is at #23
Coraline Sherratt
@removed~csherratt
@kvark this looks promising.
what will the active_value be used for?
Dzmitry Malyshau
@kvark
@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!
Coraline Sherratt
@removed~csherratt
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.
Dzmitry Malyshau
@kvark
@csherratt Ok, thanks for clarification! Let us know about your vision and requirements for the back-end so that we can work towards it. Perhaps, you want the device stuff to be separated into its own crate? Or change the direction we are heading now slightly?
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...
Dzmitry Malyshau
@kvark
@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.
Coraline Sherratt
@removed~csherratt
It has some benefits when the object count is in the hundreds of thousands. But in those cases you are normally gpu bound.
@kvark gfx-rs is your dream graphics pipeline that you one day hope OpenGL / DirectX will aspire to live up to?
Dzmitry Malyshau
@kvark
@csherratt haha, dunno if GL/DX will still exist by that moment
Coraline Sherratt
@removed~csherratt
Do you mean that in the way that gfx-rs is going to take decades to make perfect? or in the way that you think OpenGL/DirectX are going the way of the dodo?
Dzmitry Malyshau
@kvark
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.
Coraline Sherratt
@removed~csherratt
Have you looked at Mantel at all? It looked like a promising start, but then DX12 cannibalized most of the features.
of course DX12 does not exist, but the promise of said features is probably enough to spell the death of Mantle.