Amazing, Larry. Thanks a bunch.

On Tue, Jun 28, 2016 at 7:13 AM, Larry Gritz <[email protected]> wrote:

> There were some merge conflicts in applying the diff, but I managed to
> beat it into shape and integrate into RB-1.6.
>
> I'm expecting at the end of this week to tag releases, including 1.6.15
> and this patch will be part of that.
>
>
> On Jun 27, 2016, at 11:31 AM, Dan Kripac <[email protected]> wrote:
>
> Hey Larry, Soren's gone home so I'll answer for him.
>
> Our production OIIO is at 1.6.10 at the moment. We're playing with 1.6.14.
>
> Would your diffs apply or would we need a backport?
>
> Cheers
> Dan
>
> On 27 June 2016 at 18:50, Larry Gritz <[email protected]> wrote:
>
>> Søren, do you guys work from master, or do you need a backport?
>>
>>
>> On Jun 27, 2016, at 10:43 AM, Søren Ragsdale <[email protected]> wrote:
>>
>> Sorry for the delay in responding.
>>
>>
>> I've read through the diffs. If I understand correctly, I should be able
>> to:
>>
>> - ask for "total_files" and get the total number of textures that OIIO
>> knows about
>>
>> - ask for "all_filenames" and get back a list of all the textures that
>> OIIO knows about
>>
>> - run a query on each of those files and get back
>> bytesread, redundant_tiles, and other things that OIIO knows about each
>> texture.
>>
>>
>> That seems pretty useful, and seems sufficient for my purposes. Thanks!
>>
>>
>> On 18 Jun 2016 8:39 p.m., "Larry Gritz" <[email protected]> wrote:
>>
>>> How does this look, Soren?
>>> https://github.com/OpenImageIO/oiio/pull/1438
>>>
>>> Look at the last part of the diff, the part of testtex that exercises
>>> it. Look reasonable? I think this will let you extract the information you
>>> need and pack it into whatever statistics format you prefer.
>>>
>>>
>>> On Jun 16, 2016, at 11:54 AM, Larry Gritz <[email protected]> wrote:
>>>
>>> Yes, it would also require a global TextureSystem::getattribute query
>>> that returns the list of all files accessed. That would be true regardless
>>> of whether the per-file stats are accessed via get_texture_info, or if you
>>> had direct access to the internals of the ImageCacheFile struct -- either
>>> way, you sill need the list of files. Giving access to the deep internals
>>> of the data structure necessary to construct that list yourself seems well
>>> into "TMI" territory. No good can come from making those internals part of
>>> the public API and losing the freedom to change them at will.
>>>
>>> Let me mock something up and make a preliminary PR, and see if it looks
>>> like the right direction, and then if so, I can make it more complete.
>>>
>>> -- lg
>>>
>>>
>>> On Jun 16, 2016, at 2:04 AM, Søren Ragsdale <[email protected]> wrote:
>>>
>>> I'm not sure that's a good solution in this case. I don't want to ask
>>> about any particular texture - I'd like to get a list of all the textures
>>> that OIIO knows about, at which point I guess I could query the statistics
>>> for each one of them.
>>>
>>> On Thu, Jun 16, 2016 at 12:59 AM, Larry Gritz <[email protected]> wrote:
>>>
>>>> I'm uncomfortable exposing the internals of the file record struct from
>>>> the ImageCache.
>>>>
>>>> But I can offer a cleaner solution:
>>>>
>>>> Just like you can retrieve various TextureSystem-wide statistics via
>>>> TS::getattribute("stats:foo", ...), perhaps I can add an API function that
>>>> lets you ask for statistics associated with a particular file. In fact, we
>>>> should probably simply use the existing get_texture_info(), and I can make
>>>> it aware of tags that retrieve the statistics. Then you can retrieve those
>>>> in a way that's not dependent on the internals which may change, and
>>>> assemble them into the XML or any other format you want.
>>>>
>>>> Does that sound reasonable?
>>>>
>>>>
>>>> > On Jun 15, 2016, at 3:05 AM, Søren Ragsdale <[email protected]> wrote:
>>>> >
>>>> > OIIO provides a OSL::TextureSystem.getstats() call, which is useful
>>>> if you'd like to see OIIO stats represented as one large string.
>>>> >
>>>> > We're using OIIO inside OSL inside Prman-20. I'd like to stuff OIIO's
>>>> texture access stats into Prman's XML-formatted logfile. But in order to do
>>>> this, we need to have access to m_files which is a private member.
>>>> >
>>>> > Could we get some kind of const access function for m_files?
>>>> >
>>>>
>>>> --
>>>> Larry Gritz
>>>> [email protected]
>>>>
>>>>
>>>> _______________________________________________
>>>> Oiio-dev mailing list
>>>> [email protected]
>>>> http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
>>>>
>>>
>>> _______________________________________________
>>> Oiio-dev mailing list
>>> [email protected]
>>> http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
>>>
>>>
>>> --
>>> Larry Gritz
>>> [email protected]
>>>
>>>
>>> _______________________________________________
>>> Oiio-dev mailing list
>>> [email protected]
>>> http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
>>>
>>>
>>> --
>>> Larry Gritz
>>> [email protected]
>>>
>>>
>>>
>>> _______________________________________________
>>> Oiio-dev mailing list
>>> [email protected]
>>> http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
>>>
>>> _______________________________________________
>> Oiio-dev mailing list
>> [email protected]
>> http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
>>
>>
>> --
>> Larry Gritz
>> [email protected]
>>
>>
>>
>> _______________________________________________
>> Oiio-dev mailing list
>> [email protected]
>> http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
>>
>>
> _______________________________________________
> Oiio-dev mailing list
> [email protected]
> http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
>
>
> --
> Larry Gritz
> [email protected]
>
>
>
> _______________________________________________
> Oiio-dev mailing list
> [email protected]
> http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
>
>
_______________________________________________
Oiio-dev mailing list
[email protected]
http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org

Reply via email to