Hi,
Thanks for your reply.
1. Yes. I think current SSE code path may be fatser than Beignet still.
So it is our focus area.
We hope to optimize Beignet continuslly for improving OpenCL path
speed.
Finally, we hope it could be fatser than SSE CPU path.
2. Yes. I am also using darktable-cli for my evaluation.
3. If found any OpenCL related issues, could you please let me know?
Thanks again.
yan.wang
From: johannes hanika
Date: 2017-02-24 16:41
To: yan.wang
CC: darktable-dev
Subject: Re: Re: [darktable-dev] Darktable on Beignet
hi,
good to hear you found this issue! thanks again for looking into it.
we don't have an official benchmark. there was one thing on the
phoronix website, but there seems to be a discourse about whether this
is in fact a good benchmark. i'm not too sure how to improve it
though, in the end it would always boil down to using darktable-cli
with some set of xmp files and raw input files.
i suppose we can give beignet some more testing now that you're
committed to improving it :) fixing one issue is no proof yet that it
works in all cases.
as to the blacklist: there's also the question whether this makes
sense to the end user. did you profile our built-in SSE cpu codepath
vs. beignet? my bet is that the hand optimised code would still be
faster in many cases and thus be preferable to end users.
cheers,
jo
On Fri, Feb 24, 2017 at 7:44 AM, yan.wang <[email protected]> wrote:
> Hi,
> Now I have found the root cause and fixed it. The patch has been merged
> into Beignet master.
> It comes from emiting instruction of mad of Beignet when processing the
> following in vng_interpolate().
> const float diff = fabs(XXXX) * weight;
> when "gval[x] += diff" is convert mad instruction, fabs() hasn't been
> processed rightly.
> It causes the following result:
> gmin: -0.047253 gmax: -0.001124 thold: -0.047815
> All gvals are greater than thold because they are negtive.
> It makes num be zero and causes /0 error.
> Could you please confirm it and release Beignet from the black list if
> confirmed?
> https://cgit.freedesktop.org/beignet/
> BTW, I am glad to contiune to improve the performance of darktable on
> beignet in the future.
> Is there a official benchmark for these darktable OCL kernels for
> evaluation?
> Thanks.
>
>
> ________________________________
> yan.wang
>
>
> From: johannes hanika
> Date: 2017-02-22 19:00
> To: yan.wang
> CC: darktable-dev
> Subject: Re: Re: [darktable-dev] Darktable on Beignet
> hi,
>
> sorry, i don't think your patch is okay.
>
> if gmin == 0.0 that means there should be at least one element in
> gval[.] == 0.0. this should, regardless of gmax, evaluate (gval[g] <=
> thold) as true. if that is not the case there is something else wrong
> in the control flow.
>
> -jo
>
> On Wed, Feb 22, 2017 at 10:40 AM, yan.wang <[email protected]> wrote:
>> Hi,
>> Thanks for your replying.
>> I add printf into this kernel for dump gmin and gmax in this case on
>> my
>> platform.
>> And I find that gmin has the value "0.00000" but gamx is 0.04.
>> But thold = gmin + (gmax * 0.5f). if gmin = 0.0f, it may cause thold
>> has
>> only gmax / 2.
>> I think it may cause if (gval[g] <= thold) section will not be entered
>> because float caluclation may not be used equaltion comparation
>> prcisionlly.
>> I am not familiar with the algorithm of demosaic.
>> If my patch is OK, could you please merge it and remove beignet from
>> black list?
>> Thanks.
>>
>> Yan Wang
>>
>> ________________________________
>> yan.wang
>>
>>
>> From: johannes hanika
>> Date: 2017-02-22 17:11
>> To: yan.wang
>> CC: darktable-dev
>> Subject: Re: Re: [darktable-dev] Darktable on Beignet
>> hi,
>>
>> thanks for looking into this!
>>
>> /0 is not nice in any case.. but i doubt your fix is the best we can
>> do. num should be incremented whenever a value is smaller than or
>> equal to a threshold, which is chosen based on the min and max of
>> these very values. the case num==0 should really never happen (and
>> it's not safeguarded in the cpu code path either).
>>
>> at least the one case of the one gval[g] that is == gmin, the case
>> if(gval[g] <= thold) should trigger, no? the edge case being
>> gmin=gmax=thold which should be covered by the == case. maybe
>> something in the computation of these min and max went wrong?
>>
>> cheers,
>> jo
>>
>> On Wed, Feb 22, 2017 at 8:39 AM, yan.wang <[email protected]>
>> wrote:
>>> Hi, Roman,
>>> I debugged darktable on beignet on my Skylake and Chrry View platfrom
>>> by
>>> your DNG and XMP files.
>>> I use the latest beignet master.
>>> The result seems some wrong with CPU version but is also different
>>> with
>>> screenshot result of bugzilla.
>>> Please review my attached screenshot file.
>>> For this issue, I found that it is related with the OCL kernel named
>>> with vng_interpolate() in demosaic_vng.cl.
>>> In this kernel, variable named with "num" may be zero and cause
>>> dividing
>>> zero error.
>>> After modify it like my attached patch, this issue will disappear.
>>> I haven't compared OCL kernel and CPU version.
>>> So I am not sure whether "num == 0" is right.
>>> I also will check the processing flow of "dividing zero" in Beignet.
>>> Thanks.
>>>
>>> ________________________________
>>> yan.wang
>>>
>>>
>>> From: Roman Lebedev
>>> Date: 2017-02-16 19:37
>>> To: yan.wang
>>> CC: darktable-dev
>>> Subject: Re: [darktable-dev] Darktable on Beignet
>>> On Thu, Feb 16, 2017 at 11:11 AM, yan.wang <[email protected]>
>>> wrote:
>>>> Hi,
>>>> I am Beignet devloper from Intel.
>>> Hi.
>>>
>>>> Just I found Beignet is pushed into the blacklist of darktable
>>>> because
>>>> of one bug.
>>>> http://www.darktable.org/2016/12/darktable-2-2-0rc3-released/
>>>> I want to fix it but I don't know how to reproduce it.
>>> In this particular case, i blacklisted it because of
>>> https://redmine.darktable.org/issues/11358
>>>
>>> To reproduce, i guess you'd need
>>> https://redmine.darktable.org/attachments/download/2799/CRW_9672.DNG
>>> and
>>> https://redmine.darktable.org/attachments/download/2803/CRW_9672.DNG.xmp
>>>
>>> Disable blacklist (echo "opencl_disable_drivers_blacklist=true >>
>>> ~/.config/darktable/darktablerc")
>>> Start dt
>>> Import image
>>> Select it (highlight the image, click on it once)
>>> In right sidepanel, in "History stack" module, click on "load sidecar
>>> file", and select that XMP.
>>>
>>> Maybe this particular issue is already fixed, maybe it is not.
>>>
>>>> Who could help me?
>>>> Thanks.
>>>>
>>>> ________________________________
>>>> yan.wang
>>> Roman.
>>>
>>>>
>>>>
>>>>
>>>> ___________________________________________________________________________
>>>> darktable developer mailing list to unsubscribe send a mail to
>>>> [email protected]
>>>
>>>
>>>
>>>
>>> ___________________________________________________________________________
>>> darktable developer mailing list to unsubscribe send a mail to
>>> [email protected]
> ___________________________________________________________________________
> darktable developer mailing list
> to unsubscribe send a mail to [email protected]
>
___________________________________________________________________________
darktable developer mailing list
to unsubscribe send a mail to [email protected]
