On 13 January 2017 at 21:59, Jason Ekstrand wrote:
> Also, something I would like to see (maybe a follow-on patch?) would a
> change to the mesa internal API to be able to put the SHA context on the
> stack and not need to malloc it. It's not really a memory or cycle-saving
> thing so much as it
On Jan 18, 2017 8:07 AM, "Emil Velikov" wrote:
On 18 January 2017 at 09:43, Timothy Arceri
wrote:
> I'm all for
> importing an implementation I just wanted to be sure we make a good
> choice as we will likely be stuck with it for a long time.
>
Would you like to give it some more testing/benchm
On 18 January 2017 at 09:43, Timothy Arceri
wrote:
> I'm all for
> importing an implementation I just wanted to be sure we make a good
> choice as we will likely be stuck with it for a long time.
>
Would you like to give it some more testing/benchmarking, or I can
consider this ack-by ;-)
Thanks
On 18 January 2017 at 09:57, Steven Newbury wrote:
> On Wed, 2017-01-18 at 20:43 +1100, Timothy Arceri wrote:
>> On Wed, 2017-01-18 at 08:30 +, Steven Newbury wrote
> [SNIP]
>> >
>> > Why not leave in a build time option for whichever is the fastest
>> > (non-
>> > OpenSSL) external SHA1 imple
On Wed, 2017-01-18 at 20:43 +1100, Timothy Arceri wrote:
> On Wed, 2017-01-18 at 08:30 +, Steven Newbury wrote
[SNIP]
> >
> > Why not leave in a build time option for whichever is the fastest
> > (non-
> > OpenSSL) external SHA1 implementation but default or fallback to
> > whatever gets pulle
On Wed, 2017-01-18 at 08:30 +, Steven Newbury wrote:
> On Mon, 2017-01-16 at 16:52 +0300, Vladislav Egorov wrote:
> >
> > 16.01.2017 16:13, Emil Velikov пишет:
> > > Hi Vladislav,
> > >
> > > On 14 January 2017 at 01:50, Vladislav Egorov > > om
> > > > wrote:
> > > > 14.01.2017 01:45, Timoth
On Mon, 2017-01-16 at 16:52 +0300, Vladislav Egorov wrote:
>
> 16.01.2017 16:13, Emil Velikov пишет:
> > Hi Vladislav,
> >
> > On 14 January 2017 at 01:50, Vladislav Egorov > > wrote:
> > > 14.01.2017 01:45, Timothy Arceri пишет:
> > > > I'm asking for a chance to test before we jump in, its pro
16.01.2017 16:13, Emil Velikov пишет:
Hi Vladislav,
On 14 January 2017 at 01:50, Vladislav Egorov wrote:
14.01.2017 01:45, Timothy Arceri пишет:
I'm asking for a chance to test before we jump in, its probably not a
big deal and I may even still be able to reduce my use of hashing but
it wou
On 14 January 2017 at 06:25, Jonathan Gray wrote:
> On Fri, Jan 13, 2017 at 04:51:31PM +, Emil Velikov wrote:
>> From: Emil Velikov
>>
>> At the moment we support 5+ different implementations each with varying
>> amount of bugs - from thread safely problems [1], to outright broken
>> implemen
Hi Vladislav,
On 14 January 2017 at 01:50, Vladislav Egorov wrote:
> 14.01.2017 01:45, Timothy Arceri пишет:
>>
>> I'm asking for a chance to test before we jump in, its probably not a
>> big deal and I may even still be able to reduce my use of hashing but
>> it would be nice to be given a few d
Yes! Simplifies current situation quite a bit and makes Vulkan Android
build possible, I'll submit that if/when this one lands.
There's one thing that caused problems with Android, I've marked it
below .. with that removed;
Acked-by: Tapani Pälli
On 01/13/2017 06:51 PM, Emil Velikov wrote:
On Sat, 2017-01-14 at 04:50 +0300, Vladislav Egorov wrote:
> 14.01.2017 01:45, Timothy Arceri пишет:
> > I'm asking for a chance to test before we jump in, its probably not
> > a
> > big deal and I may even still be able to reduce my use of hashing
> > but
> > it would be nice to be given a few day
On Fri, Jan 13, 2017 at 04:51:31PM +, Emil Velikov wrote:
> From: Emil Velikov
>
> At the moment we support 5+ different implementations each with varying
> amount of bugs - from thread safely problems [1], to outright broken
> implementation(s) [2]
>
> In order to accommodate these we have
14.01.2017 01:45, Timothy Arceri пишет:
I'm asking for a chance to test before we jump in, its probably not a
big deal and I may even still be able to reduce my use of hashing but
it would be nice to be given a few days to test and even explore
alternatives before jumping on this implementation.
Thanks for the comments gents.
This is the type of discussion I was aiming at.
On 13 January 2017 at 22:45, Timothy Arceri
wrote:
> On Fri, 2017-01-13 at 14:32 -0800, Jason Ekstrand wrote:
>> On Fri, Jan 13, 2017 at 2:18 PM, Timothy Arceri > bora.com> wrote:
>> > On Fri, 2017-01-13 at 13:59 -080
On Fri, 2017-01-13 at 14:32 -0800, Jason Ekstrand wrote:
> On Fri, Jan 13, 2017 at 2:18 PM, Timothy Arceri bora.com> wrote:
> > On Fri, 2017-01-13 at 13:59 -0800, Jason Ekstrand wrote:
> > > On Fri, Jan 13, 2017 at 11:22 AM, Vladislav Egorov > ail.
> > > com> wrote:
> > > > 13.01.2017 19:51, Emil
On Fri, Jan 13, 2017 at 2:18 PM, Timothy Arceri <
timothy.arc...@collabora.com> wrote:
> On Fri, 2017-01-13 at 13:59 -0800, Jason Ekstrand wrote:
> > On Fri, Jan 13, 2017 at 11:22 AM, Vladislav Egorov > com> wrote:
> > > 13.01.2017 19:51, Emil Velikov пишет:
> > > > From: Emil Velikov
> > > >
>
14.01.2017 00:17, Matt Turner пишет:
On Fri, Jan 13, 2017 at 1:01 PM, Vladislav Egorov wrote:
2017-01-13 22:43 GMT+03:00 Emil Velikov :
On 13 January 2017 at 19:22, Vladislav Egorov wrote:
13.01.2017 19:51, Emil Velikov пишет:
From: Emil Velikov
At the moment we support 5+ different imp
On Fri, 2017-01-13 at 13:59 -0800, Jason Ekstrand wrote:
> On Fri, Jan 13, 2017 at 11:22 AM, Vladislav Egorov com> wrote:
> > 13.01.2017 19:51, Emil Velikov пишет:
> > > From: Emil Velikov
> > >
> > > At the moment we support 5+ different implementations each with
> > > varying
> > > amount of b
On Fri, Jan 13, 2017 at 11:22 AM, Vladislav Egorov
wrote:
> 13.01.2017 19:51, Emil Velikov пишет:
>
>> From: Emil Velikov
>>
>> At the moment we support 5+ different implementations each with varying
>> amount of bugs - from thread safely problems [1], to outright broken
>> implementation(s) [2]
On Fri, Jan 13, 2017 at 1:01 PM, Vladislav Egorov wrote:
> 2017-01-13 22:43 GMT+03:00 Emil Velikov :
>>
>> On 13 January 2017 at 19:22, Vladislav Egorov wrote:
>> > 13.01.2017 19:51, Emil Velikov пишет:
>> >>
>> >> From: Emil Velikov
>> >>
>> >> At the moment we support 5+ different implementati
I am generally in favor of this for all the reasons you've described.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
2017-01-13 22:43 GMT+03:00 Emil Velikov :
>
> On 13 January 2017 at 19:22, Vladislav Egorov wrote:
> > 13.01.2017 19:51, Emil Velikov пишет:
> >>
> >> From: Emil Velikov
> >>
> >> At the moment we support 5+ different implementations each with varying
> >> amount of bugs - from thread safely prob
On Fri, Jan 13, 2017 at 11:51 AM, Dylan Baker wrote:
> Quoting Emil Velikov (2017-01-13 08:51:31)
>> From: Emil Velikov
>>
>> At the moment we support 5+ different implementations each with varying
>> amount of bugs - from thread safely problems [1], to outright broken
>> implementation(s) [2]
>>
Quoting Emil Velikov (2017-01-13 08:51:31)
> From: Emil Velikov
>
> At the moment we support 5+ different implementations each with varying
> amount of bugs - from thread safely problems [1], to outright broken
> implementation(s) [2]
>
> In order to accommodate these we have 150+ lines of confi
On 13 January 2017 at 19:22, Vladislav Egorov wrote:
> 13.01.2017 19:51, Emil Velikov пишет:
>>
>> From: Emil Velikov
>>
>> At the moment we support 5+ different implementations each with varying
>> amount of bugs - from thread safely problems [1], to outright broken
>> implementation(s) [2]
>>
>
13.01.2017 19:51, Emil Velikov пишет:
From: Emil Velikov
At the moment we support 5+ different implementations each with varying
amount of bugs - from thread safely problems [1], to outright broken
implementation(s) [2]
In order to accommodate these we have 150+ lines of configure script and
e
From: Emil Velikov
At the moment we support 5+ different implementations each with varying
amount of bugs - from thread safely problems [1], to outright broken
implementation(s) [2]
In order to accommodate these we have 150+ lines of configure script and
extra two configure toggles. Whist an act
28 matches
Mail list logo
