search

pombreda / alembic

Automatically exported from code.google.com/p/alembic
Other
0 stars 0 forks source link

setReadArraySampleCachePtr isn't multithread safe #204

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago 
Since the current SampleCache isn't used this isn't a critical issue, but when 
we do build a real CacheImpl the methods setReadArraySampleCachePtr in IArchive 
and ArImpl will have to address this.

Original issue reported on code.google.com by ble...@gmail.com on 21 Jul 2011 at 6:25

GoogleCodeExporter commented 9 years ago 
The sample cache is not really useful in any real application and isnt' likely 
going to be fixed.

Original comment by ble...@gmail.com on 24 Aug 2011 at 11:39

GoogleCodeExporter commented 9 years ago 
Lucas, can you elaborate a bit more on that?  Why wouldn't the cache be useful 
in any case ever...?

Original comment by tommy.bu...@gmail.com on 24 Aug 2011 at 11:51

GoogleCodeExporter commented 9 years ago 
Technically Brian mentioned this, but I will defend it anyway, since I agree 
with it.

First, he didn't say it wasn't ever useful, it's just not useful in practice, 
here is why:

All of the applications I've dealt with, OpenGL, Maya, Katana, etc, have their 
own internal structures that you need to copy the data into, so you ALWAYS need 
to copy over the data from the ArraySamplePtr into the GLFloat array, 
MFloatArray or whatever.

The plugin developer will want to store this in their applications native cache 
form when available anyway, so if they happened to use Alembics cache and their 
application specific cache, they would be using twice as much memory, this is 
clearly very bad.

The very best way to do reading at the lower levels is to have 3 different 
methods:
1. read just the key (already have)
2. read just the data, but not the key (don't have)
3. read the data and the key (currently happens via the read which gets the 
ArraySamplePtr)

Original comment by miller.lucas on 25 Aug 2011 at 12:18

GoogleCodeExporter commented 9 years ago 
Okay, sorry for the misattribution (I swear I saw your name on it but I see 
Brian's now :)  And thanks for reminding me about the need to copy out to 
internal data structures in many cases.  My gut still says there is a future 
where code could be re-worked to pull or draw directly from the abc stream and 
not copy and the promise of keeping one copy of the geom in memory when drawing 
bazillions of something is still tantalizing, I would hate to see fixing this 
get completely put off.  The original note implied this should just be ignored 
but please let's not.  Not the hottest priority perhaps, but not the lowest 
either.

Thanks,

Original comment by tommy.bu...@gmail.com on 25 Aug 2011 at 10:37

GoogleCodeExporter commented 9 years ago 
The problem is that the one copy you want to keep in memory is an application 
specific copy.

Original comment by miller.lucas on 25 Aug 2011 at 10:40

GoogleCodeExporter commented 9 years ago

Original comment by ble...@gmail.com on 25 Aug 2011 at 10:50

GoogleCodeExporter commented 9 years ago

Original comment by ble...@gmail.com on 27 Aug 2011 at 12:00

GoogleCodeExporter commented 9 years ago 
Adding to Milestone 1.1

Original comment by scottmmo...@gmail.com on 6 Sep 2011 at 11:10

GoogleCodeExporter commented 9 years ago

Original comment by ble...@gmail.com on 19 Sep 2011 at 9:51

GoogleCodeExporter commented 9 years ago 
hdf5 internally caches all data access anyway.
If you want more cache, you can simply read about how it works and how to set 
it in the hdf5 documentation here:

http://www.hdfgroup.org/HDF5/doc/H5.user/Caching.html

I'm not sure why you would want to duplicate such functionality in Alembic, 
since it's underlying subsystem (hdf5) already does this perfectly well.

Original comment by evolutio...@gmail.com on 16 Feb 2012 at 1:49

GoogleCodeExporter commented 9 years ago 
The keys allow you to avoid reading the same data in different HDF5 files.

We aren't duplicating hdf5's caching functionality in Alembic.

Original comment by miller.lucas on 16 Feb 2012 at 5:22

GoogleCodeExporter commented 9 years ago

Original comment by miller.lucas on 25 Jun 2012 at 6:43

GoogleCodeExporter commented 9 years ago

Original comment by miller.lucas on 13 Sep 2013 at 5:51