gallium state tracker calls calloc for 0 sizes arrays ?

gallium state tracker calls calloc for 0 sizes arrays ?

[Hans de Goede]

Hi All,

While debugging: https://bugzilla.redhat.com/show_bug.cgi?id=1008089

I made a apitrace recording of the a single slide transition
animation, and since I suspected memory corruption replayed
it using ElectrFence + glretrace, this finds a 0 sized array
allocation at src/mesa/state_tracker/st_glsl_to_tgsi.cpp: 5565:

    if (proginfo->Parameters) {
       t->constants = (struct ureg_src *)
          calloc(proginfo->Parameters->NumParameters, sizeof(t->constants[0]));

And if I protect the code against that one, another one at 5618:

    t->immediates = (struct ureg_src *)
       calloc(program->num_immediates, sizeof(struct ureg_src));

With the regular glibc malloc these both succeed as it actually
returns a valid memory address (posix says it may also return NULL)

I believe that the fragment program in question comes from:

src/mesa/main/state.c update_program() and then from the

    else if (ctx->FragmentProgram._MaintainTexEnvProgram) {
       /* Use fragment program generated from fixed-function state */

    }

block.

Interestingly enough if I allow malloc(0) to proceed from ElectricFence,
then the glretrace runs fine, and even renders correctly, where as
running the same gl command stream from libreoffice impress leads
to missrendering on nv3c.

So 2 questions:

1) Is it normal / expected for st_translate_program() to get called
with an empty but not NULL proginfo->Parameters resp. num_immediates == 0 ?

If not where would I begin to look for finding the culprit of this ?


2) Since the glretrace does work outside of libreoffice impress, I think
it may have something to do with the visual chosen by libreoffice impress,
is there an easy way to find out what visual lo is choosing?

Regards,

Hans


_______________________________________________
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau

Re: gallium state tracker calls calloc for 0 sizes arrays ?

[Marek Olšák]

On Thu, Aug 27, 2015 at 3:09 PM, Hans de Goede <hdegoede@redhat.com> wrote:
> Hi All,
>
> While debugging: https://bugzilla.redhat.com/show_bug.cgi?id=1008089
>
> I made a apitrace recording of the a single slide transition
> animation, and since I suspected memory corruption replayed
> it using ElectrFence + glretrace, this finds a 0 sized array
> allocation at src/mesa/state_tracker/st_glsl_to_tgsi.cpp: 5565:
>
>    if (proginfo->Parameters) {
>       t->constants = (struct ureg_src *)
>          calloc(proginfo->Parameters->NumParameters,
> sizeof(t->constants[0]));
>
> And if I protect the code against that one, another one at 5618:
>
>    t->immediates = (struct ureg_src *)
>       calloc(program->num_immediates, sizeof(struct ureg_src));
>
> With the regular glibc malloc these both succeed as it actually
> returns a valid memory address (posix says it may also return NULL)
>
> I believe that the fragment program in question comes from:
>
> src/mesa/main/state.c update_program() and then from the
>
>    else if (ctx->FragmentProgram._MaintainTexEnvProgram) {
>       /* Use fragment program generated from fixed-function state */
>
>    }
>
> block.
>
> Interestingly enough if I allow malloc(0) to proceed from ElectricFence,
> then the glretrace runs fine, and even renders correctly, where as
> running the same gl command stream from libreoffice impress leads
> to missrendering on nv3c.
>
> So 2 questions:
>
> 1) Is it normal / expected for st_translate_program() to get called
> with an empty but not NULL proginfo->Parameters resp. num_immediates == 0 ?
>
> If not where would I begin to look for finding the culprit of this ?

Yes, it's normal.

>
>
> 2) Since the glretrace does work outside of libreoffice impress, I think
> it may have something to do with the visual chosen by libreoffice impress,
> is there an easy way to find out what visual lo is choosing?

No, it's not because of the visual. It seems to me that libreoffice
changed the behavior of malloc and calloc.

Marek
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] gallium state tracker calls calloc for 0 sizes arrays ?

[Hans de Goede]

Hi,

On 27-08-15 15:46, Marek Olšák wrote:
> On Thu, Aug 27, 2015 at 3:09 PM, Hans de Goede <hdegoede@redhat.com> wrote:
>> Hi All,
>>
>> While debugging: https://bugzilla.redhat.com/show_bug.cgi?id=1008089
>>
>> I made a apitrace recording of the a single slide transition
>> animation, and since I suspected memory corruption replayed
>> it using ElectrFence + glretrace, this finds a 0 sized array
>> allocation at src/mesa/state_tracker/st_glsl_to_tgsi.cpp: 5565:
>>
>>     if (proginfo->Parameters) {
>>        t->constants = (struct ureg_src *)
>>           calloc(proginfo->Parameters->NumParameters,
>> sizeof(t->constants[0]));
>>
>> And if I protect the code against that one, another one at 5618:
>>
>>     t->immediates = (struct ureg_src *)
>>        calloc(program->num_immediates, sizeof(struct ureg_src));
>>
>> With the regular glibc malloc these both succeed as it actually
>> returns a valid memory address (posix says it may also return NULL)
>>
>> I believe that the fragment program in question comes from:
>>
>> src/mesa/main/state.c update_program() and then from the
>>
>>     else if (ctx->FragmentProgram._MaintainTexEnvProgram) {
>>        /* Use fragment program generated from fixed-function state */
>>
>>     }
>>
>> block.
>>
>> Interestingly enough if I allow malloc(0) to proceed from ElectricFence,
>> then the glretrace runs fine, and even renders correctly, where as
>> running the same gl command stream from libreoffice impress leads
>> to missrendering on nv3c.
>>
>> So 2 questions:
>>
>> 1) Is it normal / expected for st_translate_program() to get called
>> with an empty but not NULL proginfo->Parameters resp. num_immediates == 0 ?
>>
>> If not where would I begin to look for finding the culprit of this ?
>
> Yes, it's normal.

OK, thanks for the clear answer on this.

>> 2) Since the glretrace does work outside of libreoffice impress, I think
>> it may have something to do with the visual chosen by libreoffice impress,
>> is there an easy way to find out what visual lo is choosing?
>
> No, it's not because of the visual. It seems to me that libreoffice
> changed the behavior of malloc and calloc.

I'm pretty sure that this is not libreoffice changing malloc / calloc,
it links normally to libc, and the same slide transition works fine
with an nv84 card which also has a gallium based mesa driver.

I really believe this is due to libreoffice doing something opengl
related differently then glretrace, be it the visual or something else
back buffer related ...

Regards,

Hans
_______________________________________________
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau

Re: gallium state tracker calls calloc for 0 sizes arrays ?

[Alex Deucher]

On Thu, Aug 27, 2015 at 1:55 PM, Hans de Goede <hdegoede@redhat.com> wrote:
> Hi,
>
> On 27-08-15 15:46, Marek Olšák wrote:
>>
>> On Thu, Aug 27, 2015 at 3:09 PM, Hans de Goede <hdegoede@redhat.com>
>> wrote:
>>>
>>> Hi All,
>>>
>>> While debugging: https://bugzilla.redhat.com/show_bug.cgi?id=1008089
>>>
>>> I made a apitrace recording of the a single slide transition
>>> animation, and since I suspected memory corruption replayed
>>> it using ElectrFence + glretrace, this finds a 0 sized array
>>> allocation at src/mesa/state_tracker/st_glsl_to_tgsi.cpp: 5565:
>>>
>>>     if (proginfo->Parameters) {
>>>        t->constants = (struct ureg_src *)
>>>           calloc(proginfo->Parameters->NumParameters,
>>> sizeof(t->constants[0]));
>>>
>>> And if I protect the code against that one, another one at 5618:
>>>
>>>     t->immediates = (struct ureg_src *)
>>>        calloc(program->num_immediates, sizeof(struct ureg_src));
>>>
>>> With the regular glibc malloc these both succeed as it actually
>>> returns a valid memory address (posix says it may also return NULL)
>>>
>>> I believe that the fragment program in question comes from:
>>>
>>> src/mesa/main/state.c update_program() and then from the
>>>
>>>     else if (ctx->FragmentProgram._MaintainTexEnvProgram) {
>>>        /* Use fragment program generated from fixed-function state */
>>>
>>>     }
>>>
>>> block.
>>>
>>> Interestingly enough if I allow malloc(0) to proceed from ElectricFence,
>>> then the glretrace runs fine, and even renders correctly, where as
>>> running the same gl command stream from libreoffice impress leads
>>> to missrendering on nv3c.
>>>
>>> So 2 questions:
>>>
>>> 1) Is it normal / expected for st_translate_program() to get called
>>> with an empty but not NULL proginfo->Parameters resp. num_immediates == 0
>>> ?
>>>
>>> If not where would I begin to look for finding the culprit of this ?
>>
>>
>> Yes, it's normal.
>
>
> OK, thanks for the clear answer on this.
>
>>> 2) Since the glretrace does work outside of libreoffice impress, I think
>>> it may have something to do with the visual chosen by libreoffice
>>> impress,
>>> is there an easy way to find out what visual lo is choosing?
>>
>>
>> No, it's not because of the visual. It seems to me that libreoffice
>> changed the behavior of malloc and calloc.
>
>
> I'm pretty sure that this is not libreoffice changing malloc / calloc,
> it links normally to libc, and the same slide transition works fine
> with an nv84 card which also has a gallium based mesa driver.
>
> I really believe this is due to libreoffice doing something opengl
> related differently then glretrace, be it the visual or something else
> back buffer related ...
>

Does libreoffice use llvm?  I have vague recollections of there being
issues with llvm and libreoffice in the past because radeonsi uses
llvm as well.

Alex
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Nouveau] gallium state tracker calls calloc for 0 sizes arrays ?

[Ilia Mirkin]

On Thu, Aug 27, 2015 at 1:59 PM, Alex Deucher <alexdeucher@gmail.com> wrote:
> On Thu, Aug 27, 2015 at 1:55 PM, Hans de Goede <hdegoede@redhat.com> wrote:
>> Hi,
>>
>> On 27-08-15 15:46, Marek Olšák wrote:
>>>
>>> On Thu, Aug 27, 2015 at 3:09 PM, Hans de Goede <hdegoede@redhat.com>
>>> wrote:
>>>>
>>>> Hi All,
>>>>
>>>> While debugging: https://bugzilla.redhat.com/show_bug.cgi?id=1008089
>>>>
>>>> I made a apitrace recording of the a single slide transition
>>>> animation, and since I suspected memory corruption replayed
>>>> it using ElectrFence + glretrace, this finds a 0 sized array
>>>> allocation at src/mesa/state_tracker/st_glsl_to_tgsi.cpp: 5565:
>>>>
>>>>     if (proginfo->Parameters) {
>>>>        t->constants = (struct ureg_src *)
>>>>           calloc(proginfo->Parameters->NumParameters,
>>>> sizeof(t->constants[0]));
>>>>
>>>> And if I protect the code against that one, another one at 5618:
>>>>
>>>>     t->immediates = (struct ureg_src *)
>>>>        calloc(program->num_immediates, sizeof(struct ureg_src));
>>>>
>>>> With the regular glibc malloc these both succeed as it actually
>>>> returns a valid memory address (posix says it may also return NULL)
>>>>
>>>> I believe that the fragment program in question comes from:
>>>>
>>>> src/mesa/main/state.c update_program() and then from the
>>>>
>>>>     else if (ctx->FragmentProgram._MaintainTexEnvProgram) {
>>>>        /* Use fragment program generated from fixed-function state */
>>>>
>>>>     }
>>>>
>>>> block.
>>>>
>>>> Interestingly enough if I allow malloc(0) to proceed from ElectricFence,
>>>> then the glretrace runs fine, and even renders correctly, where as
>>>> running the same gl command stream from libreoffice impress leads
>>>> to missrendering on nv3c.
>>>>
>>>> So 2 questions:
>>>>
>>>> 1) Is it normal / expected for st_translate_program() to get called
>>>> with an empty but not NULL proginfo->Parameters resp. num_immediates == 0
>>>> ?
>>>>
>>>> If not where would I begin to look for finding the culprit of this ?
>>>
>>>
>>> Yes, it's normal.
>>
>>
>> OK, thanks for the clear answer on this.
>>
>>>> 2) Since the glretrace does work outside of libreoffice impress, I think
>>>> it may have something to do with the visual chosen by libreoffice
>>>> impress,
>>>> is there an easy way to find out what visual lo is choosing?
>>>
>>>
>>> No, it's not because of the visual. It seems to me that libreoffice
>>> changed the behavior of malloc and calloc.
>>
>>
>> I'm pretty sure that this is not libreoffice changing malloc / calloc,
>> it links normally to libc, and the same slide transition works fine
>> with an nv84 card which also has a gallium based mesa driver.
>>
>> I really believe this is due to libreoffice doing something opengl
>> related differently then glretrace, be it the visual or something else
>> back buffer related ...
>>
>
> Does libreoffice use llvm?  I have vague recollections of there being
> issues with llvm and libreoffice in the past because radeonsi uses
> llvm as well.

FWIW the nv30 gallium driver will only use llvm as part of 'draw' when
falling back to the swtnl path. This should be extremely rare. But
easy enough to build mesa with --disable-gallium-llvm to double-check
(or what was the env var? DRAW_USE_LLVM=0 or something along those
lines).

  -ilia
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

nv3x libreoffice impress opengl animations not working

[Hans de Goede]

Hi,

On 27-08-15 20:19, Ilia Mirkin wrote:
> On Thu, Aug 27, 2015 at 1:59 PM, Alex Deucher <alexdeucher@gmail.com> wrote:

<snip>

>>>>> 2) Since the glretrace does work outside of libreoffice impress, I think
>>>>> it may have something to do with the visual chosen by libreoffice
>>>>> impress,
>>>>> is there an easy way to find out what visual lo is choosing?
>>>>
>>>>
>>>> No, it's not because of the visual. It seems to me that libreoffice
>>>> changed the behavior of malloc and calloc.
>>>
>>>
>>> I'm pretty sure that this is not libreoffice changing malloc / calloc,
>>> it links normally to libc, and the same slide transition works fine
>>> with an nv84 card which also has a gallium based mesa driver.
>>>
>>> I really believe this is due to libreoffice doing something opengl
>>> related differently then glretrace, be it the visual or something else
>>> back buffer related ...
>>>
>>
>> Does libreoffice use llvm?  I have vague recollections of there being
>> issues with llvm and libreoffice in the past because radeonsi uses
>> llvm as well.
>
> FWIW the nv30 gallium driver will only use llvm as part of 'draw' when
> falling back to the swtnl path. This should be extremely rare. But
> easy enough to build mesa with --disable-gallium-llvm to double-check
> (or what was the env var? DRAW_USE_LLVM=0 or something along those
> lines).

I've tried building with --disable-gallium-llvm, this does not help,
this is not really surprising since on Fedora both libreoffice and
mesa use the system llvm, so there should be no problems with them
expecting different llvm versions.

I've done some further debugging adding some debug printf-s to the
texture creation paths for nv3x, this bit is interesting, glretrace
does:

nv30_miptree_from_handle 1350x863 uniform_pitch 6144 usage 0 flags 0
nv30_miptree_create 1350x863 uniform_pitch 5440 usage 0 flags 0 bind 1 target 2

So it gets a texture from a handle, which I believe is the child-window
in which the animation will be shown, and then create another texture
with the same dimensions to serve as back buffer I presume.

ooimpress however does this:

nv30_miptree_from_handle 1350x863 uniform_pitch 6144 usage 0 flags 0
nv30_miptree_create 2700x1726 uniform_pitch 10816 usage 0 flags 0 bind a target 2
nv30_miptree_create 2700x1726 uniform_pitch 10816 usage 0 flags 0 bind 1 target 2

Notice how it is creating 2 (back?) buffers and they are twice the size of
the "sheet" area of impress to which the animation gets rendered.

I believe this is a clue to the root cause of the problem, but after this
I'm sorta stuck. Anyone got any hints on how to debug this further / where
to look ?

Thanks & Regards,

Hans
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: nv3x libreoffice impress opengl animations not working

[Ilia Mirkin]

On Fri, Aug 28, 2015 at 4:54 AM, Hans de Goede <hdegoede@redhat.com> wrote:
> Hi,
>
> On 27-08-15 20:19, Ilia Mirkin wrote:
>>
>> On Thu, Aug 27, 2015 at 1:59 PM, Alex Deucher <alexdeucher@gmail.com>
>> wrote:
>
>
> <snip>
>
>>>>>> 2) Since the glretrace does work outside of libreoffice impress, I
>>>>>> think
>>>>>> it may have something to do with the visual chosen by libreoffice
>>>>>> impress,
>>>>>> is there an easy way to find out what visual lo is choosing?
>>>>>
>>>>>
>>>>>
>>>>> No, it's not because of the visual. It seems to me that libreoffice
>>>>> changed the behavior of malloc and calloc.
>>>>
>>>>
>>>>
>>>> I'm pretty sure that this is not libreoffice changing malloc / calloc,
>>>> it links normally to libc, and the same slide transition works fine
>>>> with an nv84 card which also has a gallium based mesa driver.
>>>>
>>>> I really believe this is due to libreoffice doing something opengl
>>>> related differently then glretrace, be it the visual or something else
>>>> back buffer related ...
>>>>
>>>
>>> Does libreoffice use llvm?  I have vague recollections of there being
>>> issues with llvm and libreoffice in the past because radeonsi uses
>>> llvm as well.
>>
>>
>> FWIW the nv30 gallium driver will only use llvm as part of 'draw' when
>> falling back to the swtnl path. This should be extremely rare. But
>> easy enough to build mesa with --disable-gallium-llvm to double-check
>> (or what was the env var? DRAW_USE_LLVM=0 or something along those
>> lines).
>
>
> I've tried building with --disable-gallium-llvm, this does not help,
> this is not really surprising since on Fedora both libreoffice and
> mesa use the system llvm, so there should be no problems with them
> expecting different llvm versions.
>
> I've done some further debugging adding some debug printf-s to the
> texture creation paths for nv3x, this bit is interesting, glretrace
> does:
>
> nv30_miptree_from_handle 1350x863 uniform_pitch 6144 usage 0 flags 0
> nv30_miptree_create 1350x863 uniform_pitch 5440 usage 0 flags 0 bind 1
> target 2
>
> So it gets a texture from a handle, which I believe is the child-window
> in which the animation will be shown, and then create another texture
> with the same dimensions to serve as back buffer I presume.
>
> ooimpress however does this:
>
> nv30_miptree_from_handle 1350x863 uniform_pitch 6144 usage 0 flags 0
> nv30_miptree_create 2700x1726 uniform_pitch 10816 usage 0 flags 0 bind a
> target 2
> nv30_miptree_create 2700x1726 uniform_pitch 10816 usage 0 flags 0 bind 1
> target 2
>
> Notice how it is creating 2 (back?) buffers and they are twice the size of
> the "sheet" area of impress to which the animation gets rendered.

bind a = rt/sampler view, bind 1 = depth/stencil. However nv3x doesn't
do NPOT textures... so those sizes are a bit odd. Perhaps there's some
logic that attempts to round-up-to-nearest-POT size, but instead
multiplies width by 2?

>
> I believe this is a clue to the root cause of the problem, but after this
> I'm sorta stuck. Anyone got any hints on how to debug this further / where
> to look ?
>
> Thanks & Regards,
>
> Hans
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: nv3x libreoffice impress opengl animations not working

[Marek Olšák]

Your first question was about shader translation, but now you're
talking about texture allocations, which are completely unrelated.
Like I said, visuals and textures have NOTHING to do with shader
compilations.

Marek

On Fri, Aug 28, 2015 at 10:54 AM, Hans de Goede <hdegoede@redhat.com> wrote:
> Hi,
>
> On 27-08-15 20:19, Ilia Mirkin wrote:
>>
>> On Thu, Aug 27, 2015 at 1:59 PM, Alex Deucher <alexdeucher@gmail.com>
>> wrote:
>
>
> <snip>
>
>>>>>> 2) Since the glretrace does work outside of libreoffice impress, I
>>>>>> think
>>>>>> it may have something to do with the visual chosen by libreoffice
>>>>>> impress,
>>>>>> is there an easy way to find out what visual lo is choosing?
>>>>>
>>>>>
>>>>>
>>>>> No, it's not because of the visual. It seems to me that libreoffice
>>>>> changed the behavior of malloc and calloc.
>>>>
>>>>
>>>>
>>>> I'm pretty sure that this is not libreoffice changing malloc / calloc,
>>>> it links normally to libc, and the same slide transition works fine
>>>> with an nv84 card which also has a gallium based mesa driver.
>>>>
>>>> I really believe this is due to libreoffice doing something opengl
>>>> related differently then glretrace, be it the visual or something else
>>>> back buffer related ...
>>>>
>>>
>>> Does libreoffice use llvm?  I have vague recollections of there being
>>> issues with llvm and libreoffice in the past because radeonsi uses
>>> llvm as well.
>>
>>
>> FWIW the nv30 gallium driver will only use llvm as part of 'draw' when
>> falling back to the swtnl path. This should be extremely rare. But
>> easy enough to build mesa with --disable-gallium-llvm to double-check
>> (or what was the env var? DRAW_USE_LLVM=0 or something along those
>> lines).
>
>
> I've tried building with --disable-gallium-llvm, this does not help,
> this is not really surprising since on Fedora both libreoffice and
> mesa use the system llvm, so there should be no problems with them
> expecting different llvm versions.
>
> I've done some further debugging adding some debug printf-s to the
> texture creation paths for nv3x, this bit is interesting, glretrace
> does:
>
> nv30_miptree_from_handle 1350x863 uniform_pitch 6144 usage 0 flags 0
> nv30_miptree_create 1350x863 uniform_pitch 5440 usage 0 flags 0 bind 1
> target 2
>
> So it gets a texture from a handle, which I believe is the child-window
> in which the animation will be shown, and then create another texture
> with the same dimensions to serve as back buffer I presume.
>
> ooimpress however does this:
>
> nv30_miptree_from_handle 1350x863 uniform_pitch 6144 usage 0 flags 0
> nv30_miptree_create 2700x1726 uniform_pitch 10816 usage 0 flags 0 bind a
> target 2
> nv30_miptree_create 2700x1726 uniform_pitch 10816 usage 0 flags 0 bind 1
> target 2
>
> Notice how it is creating 2 (back?) buffers and they are twice the size of
> the "sheet" area of impress to which the animation gets rendered.
>
> I believe this is a clue to the root cause of the problem, but after this
> I'm sorta stuck. Anyone got any hints on how to debug this further / where
> to look ?
>
> Thanks & Regards,
>
> Hans
_______________________________________________
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau

Re: nv3x libreoffice impress opengl animations not working

[Hans de Goede]

Hi,

On 28-08-15 13:01, Marek Olšák wrote:
> Your first question was about shader translation, but now you're
> talking about texture allocations, which are completely unrelated.
> Like I said, visuals and textures have NOTHING to do with shader
> compilations.

My first mail in this thread had 2 questions, 1 has been answered
the other not. Note I've updated the subject to reflect this.

Regards,

Hans


>
> Marek
>
> On Fri, Aug 28, 2015 at 10:54 AM, Hans de Goede <hdegoede@redhat.com> wrote:
>> Hi,
>>
>> On 27-08-15 20:19, Ilia Mirkin wrote:
>>>
>>> On Thu, Aug 27, 2015 at 1:59 PM, Alex Deucher <alexdeucher@gmail.com>
>>> wrote:
>>
>>
>> <snip>
>>
>>>>>>> 2) Since the glretrace does work outside of libreoffice impress, I
>>>>>>> think
>>>>>>> it may have something to do with the visual chosen by libreoffice
>>>>>>> impress,
>>>>>>> is there an easy way to find out what visual lo is choosing?
>>>>>>
>>>>>>
>>>>>>
>>>>>> No, it's not because of the visual. It seems to me that libreoffice
>>>>>> changed the behavior of malloc and calloc.
>>>>>
>>>>>
>>>>>
>>>>> I'm pretty sure that this is not libreoffice changing malloc / calloc,
>>>>> it links normally to libc, and the same slide transition works fine
>>>>> with an nv84 card which also has a gallium based mesa driver.
>>>>>
>>>>> I really believe this is due to libreoffice doing something opengl
>>>>> related differently then glretrace, be it the visual or something else
>>>>> back buffer related ...
>>>>>
>>>>
>>>> Does libreoffice use llvm?  I have vague recollections of there being
>>>> issues with llvm and libreoffice in the past because radeonsi uses
>>>> llvm as well.
>>>
>>>
>>> FWIW the nv30 gallium driver will only use llvm as part of 'draw' when
>>> falling back to the swtnl path. This should be extremely rare. But
>>> easy enough to build mesa with --disable-gallium-llvm to double-check
>>> (or what was the env var? DRAW_USE_LLVM=0 or something along those
>>> lines).
>>
>>
>> I've tried building with --disable-gallium-llvm, this does not help,
>> this is not really surprising since on Fedora both libreoffice and
>> mesa use the system llvm, so there should be no problems with them
>> expecting different llvm versions.
>>
>> I've done some further debugging adding some debug printf-s to the
>> texture creation paths for nv3x, this bit is interesting, glretrace
>> does:
>>
>> nv30_miptree_from_handle 1350x863 uniform_pitch 6144 usage 0 flags 0
>> nv30_miptree_create 1350x863 uniform_pitch 5440 usage 0 flags 0 bind 1
>> target 2
>>
>> So it gets a texture from a handle, which I believe is the child-window
>> in which the animation will be shown, and then create another texture
>> with the same dimensions to serve as back buffer I presume.
>>
>> ooimpress however does this:
>>
>> nv30_miptree_from_handle 1350x863 uniform_pitch 6144 usage 0 flags 0
>> nv30_miptree_create 2700x1726 uniform_pitch 10816 usage 0 flags 0 bind a
>> target 2
>> nv30_miptree_create 2700x1726 uniform_pitch 10816 usage 0 flags 0 bind 1
>> target 2
>>
>> Notice how it is creating 2 (back?) buffers and they are twice the size of
>> the "sheet" area of impress to which the animation gets rendered.
>>
>> I believe this is a clue to the root cause of the problem, but after this
>> I'm sorta stuck. Anyone got any hints on how to debug this further / where
>> to look ?
>>
>> Thanks & Regards,
>>
>> Hans
_______________________________________________
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau

Re: nv3x libreoffice impress opengl animations not working

[Hans de Goede]

Hi,

On 28-08-15 11:02, Ilia Mirkin wrote:
> On Fri, Aug 28, 2015 at 4:54 AM, Hans de Goede <hdegoede@redhat.com> wrote:
>> Hi,
>>
>> On 27-08-15 20:19, Ilia Mirkin wrote:
>>>
>>> On Thu, Aug 27, 2015 at 1:59 PM, Alex Deucher <alexdeucher@gmail.com>
>>> wrote:
>>
>>
>> <snip>
>>
>>>>>>> 2) Since the glretrace does work outside of libreoffice impress, I
>>>>>>> think
>>>>>>> it may have something to do with the visual chosen by libreoffice
>>>>>>> impress,
>>>>>>> is there an easy way to find out what visual lo is choosing?
>>>>>>
>>>>>>
>>>>>>
>>>>>> No, it's not because of the visual. It seems to me that libreoffice
>>>>>> changed the behavior of malloc and calloc.
>>>>>
>>>>>
>>>>>
>>>>> I'm pretty sure that this is not libreoffice changing malloc / calloc,
>>>>> it links normally to libc, and the same slide transition works fine
>>>>> with an nv84 card which also has a gallium based mesa driver.
>>>>>
>>>>> I really believe this is due to libreoffice doing something opengl
>>>>> related differently then glretrace, be it the visual or something else
>>>>> back buffer related ...
>>>>>
>>>>
>>>> Does libreoffice use llvm?  I have vague recollections of there being
>>>> issues with llvm and libreoffice in the past because radeonsi uses
>>>> llvm as well.
>>>
>>>
>>> FWIW the nv30 gallium driver will only use llvm as part of 'draw' when
>>> falling back to the swtnl path. This should be extremely rare. But
>>> easy enough to build mesa with --disable-gallium-llvm to double-check
>>> (or what was the env var? DRAW_USE_LLVM=0 or something along those
>>> lines).
>>
>>
>> I've tried building with --disable-gallium-llvm, this does not help,
>> this is not really surprising since on Fedora both libreoffice and
>> mesa use the system llvm, so there should be no problems with them
>> expecting different llvm versions.
>>
>> I've done some further debugging adding some debug printf-s to the
>> texture creation paths for nv3x, this bit is interesting, glretrace
>> does:
>>
>> nv30_miptree_from_handle 1350x863 uniform_pitch 6144 usage 0 flags 0
>> nv30_miptree_create 1350x863 uniform_pitch 5440 usage 0 flags 0 bind 1
>> target 2
>>
>> So it gets a texture from a handle, which I believe is the child-window
>> in which the animation will be shown, and then create another texture
>> with the same dimensions to serve as back buffer I presume.
>>
>> ooimpress however does this:
>>
>> nv30_miptree_from_handle 1350x863 uniform_pitch 6144 usage 0 flags 0
>> nv30_miptree_create 2700x1726 uniform_pitch 10816 usage 0 flags 0 bind a
>> target 2
>> nv30_miptree_create 2700x1726 uniform_pitch 10816 usage 0 flags 0 bind 1
>> target 2
>>
>> Notice how it is creating 2 (back?) buffers and they are twice the size of
>> the "sheet" area of impress to which the animation gets rendered.
>
> bind a = rt/sampler view, bind 1 = depth/stencil. However nv3x doesn't
> do NPOT textures... so those sizes are a bit odd. Perhaps there's some
> logic that attempts to round-up-to-nearest-POT size, but instead
> multiplies width by 2?

Ok, some debugging / poking at thing further I now know where the multiply
by 2 comes from, the pipe_resource *tmpl passed into nv30_miptree_create
has templ->nr_samples = 4, and nv30_miptree_create has:

    switch (tmpl->nr_samples) {
    case 4:
       mt->ms_mode = 0x00004000;
       mt->ms_x = 1;
       mt->ms_y = 1;
       break;
    case 2:
       mt->ms_mode = 0x00003000;
       mt->ms_x = 1;
       mt->ms_y = 0;
       break;
    default:
       mt->ms_mode = 0x00000000;
       mt->ms_x = 0;
       mt->ms_y = 0;
       break;
    }

So it seems that glretrace is doing a normal rendering which works,
where as ooimpress is doing a 4 way msaa rendering which does not work.

Interestingly enough nv30_screen_get_param returns 0 for
PIPE_CAP_TEXTURE_MULTISAMPLE and for PIPE_CAP_SAMPLER_VIEW_TARGET

And this hack:

--- a/src/gallium/drivers/nouveau/nv30/nv30_screen.c
+++ b/src/gallium/drivers/nouveau/nv30/nv30_screen.c
@@ -319,7 +319,7 @@ nv30_screen_is_format_supported(struct pipe_screen *pscreen,
                                  unsigned sample_count,
                                  unsigned bindings)
  {
-   if (sample_count > 4)
+   if (sample_count > 0)
        return false;
     if (!(0x00000017 & (1 << sample_count)))
        return false;

Fixes the slide animation misrendering (and sometimes crashing)
in libreoffice impress.

As said I think this is a hack, I currently do not understand things
good enough to come up with a better fix.

Hints how to further investigate this are appreciated.

Regards,

Hans
_______________________________________________
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau

Re: nv3x libreoffice impress opengl animations not working

[Ilia Mirkin]

On Mon, Aug 31, 2015 at 8:58 AM, Hans de Goede <hdegoede@redhat.com> wrote:
> Hi,
>
>
> On 28-08-15 11:02, Ilia Mirkin wrote:
>>
>> On Fri, Aug 28, 2015 at 4:54 AM, Hans de Goede <hdegoede@redhat.com>
>> wrote:
>>>
>>> Hi,
>>>
>>> On 27-08-15 20:19, Ilia Mirkin wrote:
>>>>
>>>>
>>>> On Thu, Aug 27, 2015 at 1:59 PM, Alex Deucher <alexdeucher@gmail.com>
>>>> wrote:
>>>
>>>
>>>
>>> <snip>
>>>
>>>>>>>> 2) Since the glretrace does work outside of libreoffice impress, I
>>>>>>>> think
>>>>>>>> it may have something to do with the visual chosen by libreoffice
>>>>>>>> impress,
>>>>>>>> is there an easy way to find out what visual lo is choosing?
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> No, it's not because of the visual. It seems to me that libreoffice
>>>>>>> changed the behavior of malloc and calloc.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> I'm pretty sure that this is not libreoffice changing malloc / calloc,
>>>>>> it links normally to libc, and the same slide transition works fine
>>>>>> with an nv84 card which also has a gallium based mesa driver.
>>>>>>
>>>>>> I really believe this is due to libreoffice doing something opengl
>>>>>> related differently then glretrace, be it the visual or something else
>>>>>> back buffer related ...
>>>>>>
>>>>>
>>>>> Does libreoffice use llvm?  I have vague recollections of there being
>>>>> issues with llvm and libreoffice in the past because radeonsi uses
>>>>> llvm as well.
>>>>
>>>>
>>>>
>>>> FWIW the nv30 gallium driver will only use llvm as part of 'draw' when
>>>> falling back to the swtnl path. This should be extremely rare. But
>>>> easy enough to build mesa with --disable-gallium-llvm to double-check
>>>> (or what was the env var? DRAW_USE_LLVM=0 or something along those
>>>> lines).
>>>
>>>
>>>
>>> I've tried building with --disable-gallium-llvm, this does not help,
>>> this is not really surprising since on Fedora both libreoffice and
>>> mesa use the system llvm, so there should be no problems with them
>>> expecting different llvm versions.
>>>
>>> I've done some further debugging adding some debug printf-s to the
>>> texture creation paths for nv3x, this bit is interesting, glretrace
>>> does:
>>>
>>> nv30_miptree_from_handle 1350x863 uniform_pitch 6144 usage 0 flags 0
>>> nv30_miptree_create 1350x863 uniform_pitch 5440 usage 0 flags 0 bind 1
>>> target 2
>>>
>>> So it gets a texture from a handle, which I believe is the child-window
>>> in which the animation will be shown, and then create another texture
>>> with the same dimensions to serve as back buffer I presume.
>>>
>>> ooimpress however does this:
>>>
>>> nv30_miptree_from_handle 1350x863 uniform_pitch 6144 usage 0 flags 0
>>> nv30_miptree_create 2700x1726 uniform_pitch 10816 usage 0 flags 0 bind a
>>> target 2
>>> nv30_miptree_create 2700x1726 uniform_pitch 10816 usage 0 flags 0 bind 1
>>> target 2
>>>
>>> Notice how it is creating 2 (back?) buffers and they are twice the size
>>> of
>>> the "sheet" area of impress to which the animation gets rendered.
>>
>>
>> bind a = rt/sampler view, bind 1 = depth/stencil. However nv3x doesn't
>> do NPOT textures... so those sizes are a bit odd. Perhaps there's some
>> logic that attempts to round-up-to-nearest-POT size, but instead
>> multiplies width by 2?
>
>
> Ok, some debugging / poking at thing further I now know where the multiply
> by 2 comes from, the pipe_resource *tmpl passed into nv30_miptree_create
> has templ->nr_samples = 4, and nv30_miptree_create has:
>
>    switch (tmpl->nr_samples) {
>    case 4:
>       mt->ms_mode = 0x00004000;
>       mt->ms_x = 1;
>       mt->ms_y = 1;
>       break;
>    case 2:
>       mt->ms_mode = 0x00003000;
>       mt->ms_x = 1;
>       mt->ms_y = 0;
>       break;
>    default:
>       mt->ms_mode = 0x00000000;
>       mt->ms_x = 0;
>       mt->ms_y = 0;
>       break;
>    }
>
> So it seems that glretrace is doing a normal rendering which works,
> where as ooimpress is doing a 4 way msaa rendering which does not work.
>
> Interestingly enough nv30_screen_get_param returns 0 for
> PIPE_CAP_TEXTURE_MULTISAMPLE and for PIPE_CAP_SAMPLER_VIEW_TARGET
>
> And this hack:
>
> --- a/src/gallium/drivers/nouveau/nv30/nv30_screen.c
> +++ b/src/gallium/drivers/nouveau/nv30/nv30_screen.c
> @@ -319,7 +319,7 @@ nv30_screen_is_format_supported(struct pipe_screen
> *pscreen,
>                                  unsigned sample_count,
>                                  unsigned bindings)
>  {
> -   if (sample_count > 4)
> +   if (sample_count > 0)
>        return false;
>     if (!(0x00000017 & (1 << sample_count)))
>        return false;
>
> Fixes the slide animation misrendering (and sometimes crashing)
> in libreoffice impress.
>
> As said I think this is a hack, I currently do not understand things
> good enough to come up with a better fix.
>
> Hints how to further investigate this are appreciated.

Not surprising that ms gets somehow messed up.
PIPE_CAP_TEXTURE_MULTISAMPLE == ARB_texture_multisample, aka allowing
the existence of MS textures (as opposed to just renderbuffers) as
well as sampling from those textures. nv30 does not support the
latter. The "other" way to do MS is to create a MS visual. You can run
glretrace --samples=4 to get the same effect.

Of course I don't really see how MS can work at all with nv30 since it
doesn't support a resolve step:

   if (info.src.resource->nr_samples > 1 &&
       info.dst.resource->nr_samples <= 1 &&
       !util_format_is_depth_or_stencil(info.src.resource->format) &&
       !util_format_is_pure_integer(info.src.resource->format)) {
      debug_printf("nv30: color resolve unimplemented\n");
      return;
   }

Perhaps there's (supposed to be) some magic with the MSAA visual? Do
you see that print happening?

  -ilia
_______________________________________________
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau

Re: nv3x libreoffice impress opengl animations not working

[Hans de Goede]

Hi Ilia

On 31-08-15 18:30, Ilia Mirkin wrote:
> On Mon, Aug 31, 2015 at 8:58 AM, Hans de Goede <hdegoede@redhat.com> wrote:

<snip>

>> Interestingly enough nv30_screen_get_param returns 0 for
>> PIPE_CAP_TEXTURE_MULTISAMPLE and for PIPE_CAP_SAMPLER_VIEW_TARGET
>>
>> And this hack:
>>
>> --- a/src/gallium/drivers/nouveau/nv30/nv30_screen.c
>> +++ b/src/gallium/drivers/nouveau/nv30/nv30_screen.c
>> @@ -319,7 +319,7 @@ nv30_screen_is_format_supported(struct pipe_screen
>> *pscreen,
>>                                   unsigned sample_count,
>>                                   unsigned bindings)
>>   {
>> -   if (sample_count > 4)
>> +   if (sample_count > 0)
>>         return false;
>>      if (!(0x00000017 & (1 << sample_count)))
>>         return false;
>>
>> Fixes the slide animation misrendering (and sometimes crashing)
>> in libreoffice impress.
>>
>> As said I think this is a hack, I currently do not understand things
>> good enough to come up with a better fix.
>>
>> Hints how to further investigate this are appreciated.
>
> Not surprising that ms gets somehow messed up.
> PIPE_CAP_TEXTURE_MULTISAMPLE == ARB_texture_multisample, aka allowing
> the existence of MS textures (as opposed to just renderbuffers) as
> well as sampling from those textures. nv30 does not support the
> latter. The "other" way to do MS is to create a MS visual. You can run
> glretrace --samples=4 to get the same effect.
>
> Of course I don't really see how MS can work at all with nv30 since it
> doesn't support a resolve step:
>
>     if (info.src.resource->nr_samples > 1 &&
>         info.dst.resource->nr_samples <= 1 &&
>         !util_format_is_depth_or_stencil(info.src.resource->format) &&
>         !util_format_is_pure_integer(info.src.resource->format)) {
>        debug_printf("nv30: color resolve unimplemented\n");
>        return;
>     }
>
> Perhaps there's (supposed to be) some magic with the MSAA visual? Do
> you see that print happening?

Yes I see that print happening and that explains the misrendering I'm
seeing pretty well, it is not misrendering at all, it is just random
data from the video mem.

I've had a quick talk about this with Ben, he suggested using
the SCALED_IMAGE_FROM_MEMORY object class, as that is what the blob
is doing.

I've done some digging through the code and this translates to the
"sfim" object in the gallium nv30 code. I was wondering if I cannot
just simple call nv30_transfer_rect with the right parameters and
let it sort the blit out ?

Regards,

Hans
_______________________________________________
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau

Re: nv3x libreoffice impress opengl animations not working

[Ilia Mirkin]

On Wed, Sep 2, 2015 at 5:48 AM, Hans de Goede <hdegoede@redhat.com> wrote:
> Hi Ilia
>
> On 31-08-15 18:30, Ilia Mirkin wrote:
>>
>> On Mon, Aug 31, 2015 at 8:58 AM, Hans de Goede <hdegoede@redhat.com>
>> wrote:
>
>
> <snip>
>
>
>>> Interestingly enough nv30_screen_get_param returns 0 for
>>> PIPE_CAP_TEXTURE_MULTISAMPLE and for PIPE_CAP_SAMPLER_VIEW_TARGET
>>>
>>> And this hack:
>>>
>>> --- a/src/gallium/drivers/nouveau/nv30/nv30_screen.c
>>> +++ b/src/gallium/drivers/nouveau/nv30/nv30_screen.c
>>> @@ -319,7 +319,7 @@ nv30_screen_is_format_supported(struct pipe_screen
>>> *pscreen,
>>>                                   unsigned sample_count,
>>>                                   unsigned bindings)
>>>   {
>>> -   if (sample_count > 4)
>>> +   if (sample_count > 0)
>>>         return false;
>>>      if (!(0x00000017 & (1 << sample_count)))
>>>         return false;
>>>
>>> Fixes the slide animation misrendering (and sometimes crashing)
>>> in libreoffice impress.
>>>
>>> As said I think this is a hack, I currently do not understand things
>>> good enough to come up with a better fix.
>>>
>>> Hints how to further investigate this are appreciated.
>>
>>
>> Not surprising that ms gets somehow messed up.
>> PIPE_CAP_TEXTURE_MULTISAMPLE == ARB_texture_multisample, aka allowing
>> the existence of MS textures (as opposed to just renderbuffers) as
>> well as sampling from those textures. nv30 does not support the
>> latter. The "other" way to do MS is to create a MS visual. You can run
>> glretrace --samples=4 to get the same effect.
>>
>> Of course I don't really see how MS can work at all with nv30 since it
>> doesn't support a resolve step:
>>
>>     if (info.src.resource->nr_samples > 1 &&
>>         info.dst.resource->nr_samples <= 1 &&
>>         !util_format_is_depth_or_stencil(info.src.resource->format) &&
>>         !util_format_is_pure_integer(info.src.resource->format)) {
>>        debug_printf("nv30: color resolve unimplemented\n");
>>        return;
>>     }
>>
>> Perhaps there's (supposed to be) some magic with the MSAA visual? Do
>> you see that print happening?
>
>
> Yes I see that print happening and that explains the misrendering I'm
> seeing pretty well, it is not misrendering at all, it is just random
> data from the video mem.
>
> I've had a quick talk about this with Ben, he suggested using
> the SCALED_IMAGE_FROM_MEMORY object class, as that is what the blob
> is doing.
>
> I've done some digging through the code and this translates to the
> "sfim" object in the gallium nv30 code. I was wondering if I cannot
> just simple call nv30_transfer_rect with the right parameters and
> let it sort the blit out ?

That seems fine to me. BTW, it's sifm == scaled image from memory, not
sfim. You'll either have to fudge the width/height, or teach the
transfer methods to look at mt->ms_x/y (and make sure to treat it as a
scaled xfer if the nr_samples don't line up).

  -ilia
_______________________________________________
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau

Re: nv3x libreoffice impress opengl animations not working

[Hans de Goede]

Hi,

On 02-09-15 16:44, Ilia Mirkin wrote:
> On Wed, Sep 2, 2015 at 5:48 AM, Hans de Goede <hdegoede@redhat.com> wrote:
>> Hi Ilia

<snip>

>>> Of course I don't really see how MS can work at all with nv30 since it
>>> doesn't support a resolve step:
>>>
>>>      if (info.src.resource->nr_samples > 1 &&
>>>          info.dst.resource->nr_samples <= 1 &&
>>>          !util_format_is_depth_or_stencil(info.src.resource->format) &&
>>>          !util_format_is_pure_integer(info.src.resource->format)) {
>>>         debug_printf("nv30: color resolve unimplemented\n");
>>>         return;
>>>      }
>>>
>>> Perhaps there's (supposed to be) some magic with the MSAA visual? Do
>>> you see that print happening?
>>
>>
>> Yes I see that print happening and that explains the misrendering I'm
>> seeing pretty well, it is not misrendering at all, it is just random
>> data from the video mem.
>>
>> I've had a quick talk about this with Ben, he suggested using
>> the SCALED_IMAGE_FROM_MEMORY object class, as that is what the blob
>> is doing.
>>
>> I've done some digging through the code and this translates to the
>> "sfim" object in the gallium nv30 code. I was wondering if I cannot
>> just simple call nv30_transfer_rect with the right parameters and
>> let it sort the blit out ?
>
> That seems fine to me. BTW, it's sifm == scaled image from memory, not
> sfim. You'll either have to fudge the width/height, or teach the
> transfer methods to look at mt->ms_x/y (and make sure to treat it as a
> scaled xfer if the nr_samples don't line up).

Ok, I've gotten this to work, yeah :) I'll send out patches for this
shortly.

But even with this fixed, there still are problems with msaa:

1) On nv3x (vs nv4x) we end up using the cpu for the blit, this is
no good so I've added a patch to my patch-set to disable msaa
visuals on nv3x

2) On nv4x things mostly work, but sometimes / after a while
the gpu locks up. Attaching gdb to impress shows it is hanging waiting
for a fence which never comes.

Killing ooimpress at this point works exactly once, trying to do any
3d operations after killing impress will lockup the entire system.

When I kill impress at this point it prints a lot of messages
like these to stdout:

nouveau:        0x45070000
nouveau:        0x00000000
nouveau:        0x0004f900
nouveau:        0x04380780
nouveau:        0x000cf580
nouveau:        0x00000000
nouveau:        0x45070000
nouveau:        0x00000000
nouveau:        0x0004f900
nouveau:        0x04380000
nouveau:        0x0004f808
nouveau:        0x00000000
nouveau:        0x0008fd6c
nouveau:        0x00000000
nouveau:        0x000000a9
nouveau:        0x00020000
nouveau:        0x00000000

I've not yet seen the beginning of this list since my scroll-back
buffer is not large enough, I guess I need to reproduce this and
redirect the output to a file to get all messages.

So any hints on how to debug this ?  Could this have something
to do with the destination buffer for the msaa rendering
(so the buffer which has the image rendered at twice the
desired resolution) not having enough padding on its pitch ?

Thanks & Regards,

Hans
_______________________________________________
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau

Re: nv3x libreoffice impress opengl animations not working

[Ilia Mirkin]

On Thu, Sep 3, 2015 at 7:09 AM, Hans de Goede <hdegoede@redhat.com> wrote:
> Hi,
>
> On 02-09-15 16:44, Ilia Mirkin wrote:
>>
>> On Wed, Sep 2, 2015 at 5:48 AM, Hans de Goede <hdegoede@redhat.com> wrote:
>>>
>>> Hi Ilia
>
>
> <snip>
>
>>>> Of course I don't really see how MS can work at all with nv30 since it
>>>> doesn't support a resolve step:
>>>>
>>>>      if (info.src.resource->nr_samples > 1 &&
>>>>          info.dst.resource->nr_samples <= 1 &&
>>>>          !util_format_is_depth_or_stencil(info.src.resource->format) &&
>>>>          !util_format_is_pure_integer(info.src.resource->format)) {
>>>>         debug_printf("nv30: color resolve unimplemented\n");
>>>>         return;
>>>>      }
>>>>
>>>> Perhaps there's (supposed to be) some magic with the MSAA visual? Do
>>>> you see that print happening?
>>>
>>>
>>>
>>> Yes I see that print happening and that explains the misrendering I'm
>>> seeing pretty well, it is not misrendering at all, it is just random
>>> data from the video mem.
>>>
>>> I've had a quick talk about this with Ben, he suggested using
>>> the SCALED_IMAGE_FROM_MEMORY object class, as that is what the blob
>>> is doing.
>>>
>>> I've done some digging through the code and this translates to the
>>> "sfim" object in the gallium nv30 code. I was wondering if I cannot
>>> just simple call nv30_transfer_rect with the right parameters and
>>> let it sort the blit out ?
>>
>>
>> That seems fine to me. BTW, it's sifm == scaled image from memory, not
>> sfim. You'll either have to fudge the width/height, or teach the
>> transfer methods to look at mt->ms_x/y (and make sure to treat it as a
>> scaled xfer if the nr_samples don't line up).
>
>
> Ok, I've gotten this to work, yeah :) I'll send out patches for this
> shortly.
>
> But even with this fixed, there still are problems with msaa:
>
> 1) On nv3x (vs nv4x) we end up using the cpu for the blit, this is
> no good so I've added a patch to my patch-set to disable msaa
> visuals on nv3x
>
> 2) On nv4x things mostly work, but sometimes / after a while
> the gpu locks up. Attaching gdb to impress shows it is hanging waiting
> for a fence which never comes.
>
> Killing ooimpress at this point works exactly once, trying to do any
> 3d operations after killing impress will lockup the entire system.
>
> When I kill impress at this point it prints a lot of messages
> like these to stdout:
>
> nouveau:        0x45070000
> nouveau:        0x00000000
> nouveau:        0x0004f900
> nouveau:        0x04380780
> nouveau:        0x000cf580
> nouveau:        0x00000000
> nouveau:        0x45070000
> nouveau:        0x00000000
> nouveau:        0x0004f900
> nouveau:        0x04380000
> nouveau:        0x0004f808
> nouveau:        0x00000000
> nouveau:        0x0008fd6c
> nouveau:        0x00000000
> nouveau:        0x000000a9
> nouveau:        0x00020000
> nouveau:        0x00000000
>
> I've not yet seen the beginning of this list since my scroll-back
> buffer is not large enough, I guess I need to reproduce this and
> redirect the output to a file to get all messages.
>
> So any hints on how to debug this ?  Could this have something
> to do with the destination buffer for the msaa rendering
> (so the buffer which has the image rendered at twice the
> desired resolution) not having enough padding on its pitch ?

Those messages get printed by libdrm when the kernel rejects
something. You should also see what the kernel is rejecting and why in
dmesg... this should be instructional. Could easily be that some
mt->ms_x/y shifts are missing. Might want to make some traces of the
blob drivers running some of the more basic piglit tests with MS and
seeing what they do. [I assume you're familiar with valgrind-mmt +
demmt. If not, http://nouveau.freedesktop.org/wiki/Valgrind-mmt/ ]

  -ilia
_______________________________________________
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau

Re: nv3x libreoffice impress opengl animations not working

[Hans de Goede]

Hi,

On 03-09-15 19:36, Ilia Mirkin wrote:
> On Thu, Sep 3, 2015 at 7:09 AM, Hans de Goede <hdegoede@redhat.com> wrote:
>> Hi,
>>
>> On 02-09-15 16:44, Ilia Mirkin wrote:
>>>
>>> On Wed, Sep 2, 2015 at 5:48 AM, Hans de Goede <hdegoede@redhat.com> wrote:
>>>>
>>>> Hi Ilia
>>
>>
>> <snip>
>>
>>>>> Of course I don't really see how MS can work at all with nv30 since it
>>>>> doesn't support a resolve step:
>>>>>
>>>>>       if (info.src.resource->nr_samples > 1 &&
>>>>>           info.dst.resource->nr_samples <= 1 &&
>>>>>           !util_format_is_depth_or_stencil(info.src.resource->format) &&
>>>>>           !util_format_is_pure_integer(info.src.resource->format)) {
>>>>>          debug_printf("nv30: color resolve unimplemented\n");
>>>>>          return;
>>>>>       }
>>>>>
>>>>> Perhaps there's (supposed to be) some magic with the MSAA visual? Do
>>>>> you see that print happening?
>>>>
>>>>
>>>>
>>>> Yes I see that print happening and that explains the misrendering I'm
>>>> seeing pretty well, it is not misrendering at all, it is just random
>>>> data from the video mem.
>>>>
>>>> I've had a quick talk about this with Ben, he suggested using
>>>> the SCALED_IMAGE_FROM_MEMORY object class, as that is what the blob
>>>> is doing.
>>>>
>>>> I've done some digging through the code and this translates to the
>>>> "sfim" object in the gallium nv30 code. I was wondering if I cannot
>>>> just simple call nv30_transfer_rect with the right parameters and
>>>> let it sort the blit out ?
>>>
>>>
>>> That seems fine to me. BTW, it's sifm == scaled image from memory, not
>>> sfim. You'll either have to fudge the width/height, or teach the
>>> transfer methods to look at mt->ms_x/y (and make sure to treat it as a
>>> scaled xfer if the nr_samples don't line up).
>>
>>
>> Ok, I've gotten this to work, yeah :) I'll send out patches for this
>> shortly.
>>
>> But even with this fixed, there still are problems with msaa:
>>
>> 1) On nv3x (vs nv4x) we end up using the cpu for the blit, this is
>> no good so I've added a patch to my patch-set to disable msaa
>> visuals on nv3x
>>
>> 2) On nv4x things mostly work, but sometimes / after a while
>> the gpu locks up. Attaching gdb to impress shows it is hanging waiting
>> for a fence which never comes.
>>
>> Killing ooimpress at this point works exactly once, trying to do any
>> 3d operations after killing impress will lockup the entire system.
>>
>> When I kill impress at this point it prints a lot of messages
>> like these to stdout:
>>
>> nouveau:        0x45070000
>> nouveau:        0x00000000
>> nouveau:        0x0004f900
>> nouveau:        0x04380780
>> nouveau:        0x000cf580
>> nouveau:        0x00000000
>> nouveau:        0x45070000
>> nouveau:        0x00000000
>> nouveau:        0x0004f900
>> nouveau:        0x04380000
>> nouveau:        0x0004f808
>> nouveau:        0x00000000
>> nouveau:        0x0008fd6c
>> nouveau:        0x00000000
>> nouveau:        0x000000a9
>> nouveau:        0x00020000
>> nouveau:        0x00000000
>>
>> I've not yet seen the beginning of this list since my scroll-back
>> buffer is not large enough, I guess I need to reproduce this and
>> redirect the output to a file to get all messages.
>>
>> So any hints on how to debug this ?  Could this have something
>> to do with the destination buffer for the msaa rendering
>> (so the buffer which has the image rendered at twice the
>> desired resolution) not having enough padding on its pitch ?
>
> Those messages get printed by libdrm when the kernel rejects
> something. You should also see what the kernel is rejecting and why in
> dmesg... this should be instructional.

Here is what dmesg says:

[ 1197.850642] nouveau E[soffice.bin[3785]] fail ttm_validate
[ 1197.850648] nouveau E[soffice.bin[3785]] validating bo list
[ 1197.850654] nouveau E[soffice.bin[3785]] validate: -12
[ 1201.766955] nouveau E[soffice.bin[3785]] fail ttm_validate
[ 1201.766961] nouveau E[soffice.bin[3785]] validating bo list
[ 1201.766968] nouveau E[soffice.bin[3785]] validate: -12
[ 1201.989441] nouveau E[soffice.bin[3785]] fail ttm_validate
[ 1201.989447] nouveau E[soffice.bin[3785]] validating bo list
[ 1201.989454] nouveau E[soffice.bin[3785]] validate: -12
[ 1202.231688] nouveau E[soffice.bin[3785]] fail ttm_validate
[ 1202.231694] nouveau E[soffice.bin[3785]] validating bo list
[ 1202.231701] nouveau E[soffice.bin[3785]] validate: -12


> Could easily be that some
> mt->ms_x/y shifts are missing.

I think that the above dmesg rules that out and that instead
I should be looking into buffer management, right ? Any clues
on how to debug this, are there some kernel parameters to
log the alloc / free of bo-s and to make ttm_validate print
a reason why things are failing ?

I'm currently using dri2, shall I retry with dri3 ?

Regards,

Hans


p.s.

I've a feeling that I can only reproduce after ending an
Xorg session and starting Xorg a second time. At least in my
first session I could not reproduce with a gazillion tries
and in my second session it reproduced pretty quickly ...

_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev