nroberts changed the topic of #videocore to: Raspberry Pi Mesa drivers discussion - Logs http://freenode.irclog.whitequark.org/videocore
nroberts has quit [Ping timeout: 272 seconds]
ceyusa has quit [Ping timeout: 272 seconds]
tanty has quit [Quit: Ciao!]
tanty has joined #videocore
nroberts has joined #videocore
ceyusa has joined #videocore
jcea has quit [Ping timeout: 260 seconds]
itoral has joined #videocore
apinheiro has joined #videocore
itoral_ has joined #videocore
itoral has quit [Ping timeout: 245 seconds]
jcea has joined #videocore
<apinheiro[m]1> itoral: I have an issue with my wip code
<apinheiro[m]1> so this test
<apinheiro[m]1> dEQP-VK.api.object_management.single_alloc_callbacks.graphics_pipeline
<apinheiro[m]1> it seems that it uses a different allocationcallbacks for the pipeline that the pipeline cache
<apinheiro[m]1> so with this idea of having some shared_data, and refs
<apinheiro[m]1> what I was doing is creating the shared_data with the callbacks of the object it was creating it
<apinheiro[m]1> so if the pipeline created it (when compiling) it would use the pipeline pAllocator
<apinheiro[m]1> if the pipeline cache created it (when deserializing), it would use the pipeline cache pallocator
<apinheiro[m]1> the entry saved the allocator
<apinheiro[m]1> the problem came when it is the moment of destroy, as depending on the order of the unrefs
<apinheiro[m]1> it is one or th eother
<apinheiro[m]1> so what it happening here is that on last shared_data unref, that called _destroy
<itoral_> what do you mean it is one or the other? You're always using the pallocated you stored on the entry
<itoral_> *pAllocator
<apinheiro[m]1> <itoral_ "what do you mean it is one or th"> I mean that is first one or the other
<apinheiro[m]1> we can't control who calls the last unref
<apinheiro[m]1> so as I was saying
<apinheiro[m]1> in this case
<apinheiro[m]1> on the last unref, that called the destoy
<apinheiro[m]1> the pAllocator used to create the shared_data is not available anymore
<apinheiro[m]1> so specifically
<itoral_> ugh
<apinheiro[m]1> shared_data was created by the pipeline
<apinheiro[m]1> then ref by the pipeline cache
<apinheiro[m]1> then the pipeline is destroyed => there is still the pipeline cache ref
<apinheiro[m]1> then the pipeline cache is destroyed => the pipeline cache unrefs => crash
<itoral_> we have two options to fix that:
<apinheiro[m]1> itoral_: the solution I found, is to create the shared_data with the device alloc
<apinheiro[m]1> (create and free)
* apinheiro[m]1 waiting for itoral_ solutions
<itoral_> 1. We always allocate with the default cache allocator, assuming that the driver controls when the default cache is destroyed
<itoral_> 2. the one you proposed :)
<itoral_> I think allocating with the device allocator is fine
<apinheiro[m]1> about 1., not sure why you mention specifically the default cache
<apinheiro[m]1> this could also happen with a cache provied by the user
<apinheiro[m]1> but as 2. is alread implemented, I will go for that
<apinheiro[m]1> thanks
<apinheiro[m]1> <apinheiro[m]1 "this could also happen with a ca"> in fact, now thinking about that, as that can happens with the cache provided by the user
<apinheiro[m]1> I think that would discard that solution
<apinheiro[m]1> as we can't control when the user cache is destroyed
<apinheiro[m]1> just to clarify even more: the thing is that the default cache is only used if a "normal" cache is not provided
<apinheiro[m]1> so we also can't assume that is the default cache the one that holds the refs
<itoral_> ok, got it, in the end 1. is the same solution as 2. since I presume we use the device allocator for the default cache anyway
<apinheiro[m]1> yes,for the default cache we use it
<apinheiro[m]1> it==device allocator
itoral_ has quit [Quit: Leaving]
apinheiro has quit [Quit: Leaving]
apinheiro has joined #videocore