Re: [waffle] [PATCH 00/13] Do less validation of the context version

[Emil Velikov]

Humble ping ?

On 5 April 2016 at 22:58, Emil Velikov  wrote:
> Hi all,
>
> This is a re-spin of an ancient RFC [1] covering two (core) topics
>  - Should waffle do fine grained checking of the context version prior
> to feeding it to the driver ? Leaning towards no.
>  - Should we rely upon the library (libGL/libGLESv1/libGLESv2) presence
> to determine if context of respective API is supported ? Same sentiment.
>
> And last but not least I've thrown out a bunch of the
> wcore_error_internal() in favour of assert. Core already handles all of
> those 'default' cases, thus we can simplify things ;-)
>
> The series can be found in branch for-upstream/context-cleanups-et-al
>
> Comments and suggestion are appreciated.
> Emil
>
> [1] https://lists.freedesktop.org/archives/waffle/2015-November/001269.html
>
___
waffle mailing list
waffle@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/waffle

Re: [waffle] json, approach 2, version 2

[Emil Velikov]

On 21 April 2016 at 21:27, Frank Henigman  wrote:
> Thanks Emil and Chad for reviewing my json series.  All suggestions
> implemented in v2, except where I replied inline.  I'll hold off
> sending in case there's more back-and-forth over the first set of
> comments.

> Would also be nice if Chad merged his get-current branch
> into master, as I use it in v2.
>
Would be nice to see the series fly by the ML, although from a quick
look they look great.
We could use it to resolve some nasty implementations details in
nacl/android/others and get GBM's window_resize working.

> When comparing my json output to the landed json output I noticed that
> the landed version omits the context flags found in the old format.
> Was that deliberate?  If so I'll remove it from my json.
>
I'll refer Chad to that one.

> Not sure if I did the right thing with glx info.  Seems like all three
> sections (server, client, common) show about the same list of
> extensions.
That may be true for some vendors, but it's not the rule afaict. On my
systems running mesa + i965 and nouveau the lists do differ.
How useful the separate lists are is another topic ;-)

> That can wait until I send v2, or if anyone wants to look
> now:
> https://github.com/fjhenigman/waffle/commit/b358ac50c00ce51fae6546b1e96c9adc32fcbdc7
I've not looked in details in the github branch, but considering that
wcore_[cm]alloc is used (instead of [cm]alloc or strdup), the leak is
plugged and people are happy with the other two topics (loose common
GL data, even if we fail in print_platform_specific) (don't print
anything and/or error if print_platform_specific() is not
implemented), I'd say just do with the series.

Reviewed-by: Emil Velikov 

Emil
___
waffle mailing list
waffle@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/waffle

Re: [waffle] [RFC PATCH 0/8] Android: plus memory leaks

[Emil Velikov]

[Adding Juha-Pekka since he did a bunch of fixes in the area]

Juha-Pekka, all,

Does anyone have some recommended reading on the topic of smart
pointers and Android ?
Can anyone spare a few cycles and skim through the series ?

Thanks
Emil

On 5 April 2016 at 23:52, Emil Velikov  wrote:
> Hi all,
>
> Some ~3 month old patches that I had lying around. As they are untested,
> and likely wrong to a degree, I'm sending them as RFC.
>
> Key note here is that we're dealing with smart pointers and my C++ in
> this area isn't exactly stellar. Any input as to why some (or even all)
> of the proposed changes are wrong is greatly appreciated.
>
> Thanks
> Emil
>
___
waffle mailing list
waffle@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/waffle

Re: [waffle] [PATCH 00/29] Rework the functionality test(s)

[Emil Velikov]

Humble ping ?

On 6 January 2016 at 21:27, Emil Velikov  wrote:
> Hi all,
>
> Recently I had the chance to finish a lenghty series started some months
> ago. Namely - rework gl_basic_tests and kick waffle_test out the door.
>
> It starts with a couple of symbol fixes (maint material afaict), caught
> while experimenting with Travis-CI.
>
> Patch 3 adds a trivial --platform param and wires up the build (make
> check-func) to generate and use all possible combinations.
>
> Patches 06 through 14 add a bunch of macros, which minimise the
> duplication, and make things substantially easier/shorter add new
> platform (patch 28, platform gbm).
>
> We might want patches 15, 16 and 17 squashed, although I chose to keep
> the "import latest cmoka", "make sure it builds" and "fix the build
> warning" (this one is on the cmocka ML), separate to ease review.
>
> With patch 18, the existing cmocka user is updated - things build even
> without it, but we no longer use the deprecated API.
>
> With 20, we disable the functionality tests as we cannot convert the
> whole file at once. Immediatelly after (21) we nuke waffle_test.
>
> Patch 22, introduce a handy macro (not perfect due to cmocka API
> shortage), that makes the "add new platform" a ~10 line diff :-)
>
> The remaining patches convert the remaining platforms, one at a time, to
> top up with a small cleanup.
>
>
> The lot can be found in branch for-upstream/rework-tests over at
> https://github.com/evelikov/waffle/
>
> TL;DR - update cmocka, and use it over waffle_test. Cut gl_basic_test.c
> from ~1.2k to 0.9 loc, while adding GBM support and platform selection
> ;-) No more memory leaks with valgrind-check-func (barring driver ones).
>
> NOTE: I'll gladly rework any formatting and macro names. If possible,
> let's avoid rebase chaos (i.e. if thinking about the test... macros) and
> do them on top ?
>
> Thanks
> Emil
>
___
waffle mailing list
waffle@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/waffle

Re: [waffle] [PATCH 07/12] waffle: support platform-specific information

[Emil Velikov]

On 25 April 2016 at 04:30, Frank Henigman  wrote:
> On Sun, Apr 24, 2016 at 5:04 PM, Emil Velikov  
> wrote:
>> On 24 April 2016 at 20:52, Frank Henigman  wrote:
>>> On Sun, Apr 24, 2016 at 6:36 AM, Emil Velikov  
>>> wrote:
 On 21 April 2016 at 21:26, Frank Henigman  wrote:
> On Fri, Jan 8, 2016 at 7:44 AM, Emil Velikov  
> wrote:
>> On 6 January 2016 at 21:56, Frank Henigman  wrote:
>>> Add a platform hook so platform-specific information can be included
>>> by waffle_display_info_json().
>>>
>>> Signed-off-by: Frank Henigman 
>>> ---
>>>  src/waffle/api/waffle_display.c  | 10 +-
>>>  src/waffle/core/wcore_platform.h |  4 
>>>  2 files changed, 13 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/src/waffle/api/waffle_display.c 
>>> b/src/waffle/api/waffle_display.c
>>> index 7abe2ef..d6988ac 100644
>>> --- a/src/waffle/api/waffle_display.c
>>> +++ b/src/waffle/api/waffle_display.c
>>> @@ -367,8 +367,16 @@ waffle_display_info_json(struct waffle_display 
>>> *self, bool platform_too)
>>>
>>>  json_appendv(jj, "{", "generic", "{", "");
>>>  add_generic_info(jj, wc_self->current_context);
>>> -json_appendv(jj, "}", "}", "");
>>> +json_append(jj, "}");
>>>
>>> +if (platform_too) {
>>> +json_appendv(jj, "platform", "{", "");
>>> +if (api_platform->vtbl->display.info_json)
>>> +api_platform->vtbl->display.info_json(wc_self, jj);
>> The rest of waffle tends to set UNSUPPORTED_ON_PLATFORM if the backend
>> is missing the vfunc.
>
> I'm reluctant to set an error for something that isn't clearly an
> error (it might just be that a backend doesn't have platform-specific
> details) because it could add a burden to the user to distinguish this
> case from definite errors.
 With all respect I have to disagree. Error checking/handling is not a
 'burden'. Even if some choose to ignore it that doesn't make it less
 relevant ;-)

 Obviously things would be way easier/cleaner if things were split -
 generic info vs platform specific (or even finer). As-is, with all of
 them in one piece, no error-checking or UNSUPPORTED_ON_PLATFORM one
 gets badly formatted/corrupted json. Thus the user has no way of
 knowing if things failed for reason some, or the setup simply lacks
 the information Y that they need.
 
>>>
>>> You never get corrupt json.  If the hook isn't implemented you get
>>> different json.  In v1 you'd get an empty platform section.  In v2 the
>>> platform section (e.g. "glx" or "egl") is omitted.  This is better
>>> because:
>>> - the json consumer is in the best position to decide what to do about
>>> a missing platform section - the api shouldn't decide it's an error
>>> - the caller of waffle_display_info_json() doesn't have to check
>>> waffle error state to know if there was a "real" error, they'll know
>>> by the NULL return
>> So when someone gets an OOM (even if it's during the platform
>> specifics) NULL is returned ? That does sound a bit strange, yet again
>> I would not read too much into it.
>
> That's true - when memory runs out the whole string is lost.  I guess
> that's the trade off for the simplicity of the error handling.  I'm
> quite happy with that trade off.
>
>> As long as others are happy go with it.
>>
>>> - we don't need to implement the hook in every back end
>>>
>> Need, perhaps not. It would be pretty good though ;-)
>
> I don't want to have to try to land code (even a stub) in back ends
> which I've never even compiled (and which would be a pain in the butt
> to set up for compiling).  Waffle needs continuous integration.  (:

I could wire up waffle's github repo with Travis-CI (for Linux/MacOS
builds) and Appveyor (for Windows ones), those depend on a lengthy
series that I have on the mailing list.
For Android I'm out of ideas.

https://lists.freedesktop.org/archives/waffle/2016-January/001292.html

- Resolves issues due to old wayland/gbm on CI systems.
- Removes the leaky waffle-tests, use cmocka.
- Allows the tests to be ran independently
- Adds GBM tests.

-Emil
___
waffle mailing list
waffle@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/waffle

Re: [waffle] [PATCH 17/29] UPSTREAM: cmocka: include strings.h for strcasecmp

[Emil Velikov]

Ftr this patch has landed in upstream cmocka. If people prefer we can
re-sync out local copy with the latest version.

Personally I'm fine either way.
Emil
___
waffle mailing list
waffle@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/waffle