public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug target/105421] New: GCN offloading, raised '-mgang-private-size': 'HSA_STATUS_ERROR_MEMORY_APERTURE_VIOLATION'
@ 2022-04-28 13:26 tschwinge at gcc dot gnu.org
  2022-10-20 10:02 ` [Bug target/105421] " cvs-commit at gcc dot gnu.org
                   ` (4 more replies)
  0 siblings, 5 replies; 6+ messages in thread
From: tschwinge at gcc dot gnu.org @ 2022-04-28 13:26 UTC (permalink / raw)
  To: gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105421

            Bug ID: 105421
           Summary: GCN offloading, raised '-mgang-private-size':
                    'HSA_STATUS_ERROR_MEMORY_APERTURE_VIOLATION'
           Product: gcc
           Version: 12.0
            Status: UNCONFIRMED
          Keywords: openacc
          Severity: normal
          Priority: P3
         Component: target
          Assignee: unassigned at gcc dot gnu.org
          Reporter: tschwinge at gcc dot gnu.org
                CC: ams at gcc dot gnu.org, jules at gcc dot gnu.org
  Target Milestone: ---
            Target: GCN

As discussed in
<http://mid.mail-archive.com/87fslzspgo.fsf@dem-tschwing-1.ger.mentorg.com>,
after commit r12-8252-gb2202431910e30d8505c94d1cb9341cac7080d10 "fortran: Fix
up gfc_trans_oacc_construct [PR104717]", we need commit
r12-8311-g2a570f11a2fecf23998d7fe1d5cabad62cfe5cec "Fix up
'libgomp.oacc-fortran/print-1.f90' GCN offloading compilation [PR104717]",
however:

> That only works with the default GCN multilib '-march=fiji', testing
> on gfx803 amdfury2 system.  For all of '-march=gfx900' (amdnano2),
> '-march=gfx906' (amd_ryzen3), '-march=gfx908' (amd-instinct1), I get:
> 
>     libgomp: GCN fatal error: Asynchronous queue error
>     Runtime message: HSA_STATUS_ERROR_MEMORY_APERTURE_VIOLATION: The agent attempted to access memory beyond the largest legal address.
> 
> ..., and I still get that if lowering the allocation to the minimum,
> '-foffload-options=amdgcn-amdhsa=-mgang-private-size=560'.
> 
> This is a really simple OpenACC 'parallel' construct:
> 
>     !$acc parallel
>       write (0, '("The answer is ", I2)') var
>     !$acc end parallel
> 
> ..., which ought to launch a 1-gang x 1-worker x 1-vector GPU kernel, so
> I'd assume '-mgang-private-size=560' (or '-mgang-private-size=13579' in
> fact) is not a problem?

^ permalink raw reply	[flat|nested] 6+ messages in thread

* [Bug target/105421] GCN offloading, raised '-mgang-private-size': 'HSA_STATUS_ERROR_MEMORY_APERTURE_VIOLATION'
  2022-04-28 13:26 [Bug target/105421] New: GCN offloading, raised '-mgang-private-size': 'HSA_STATUS_ERROR_MEMORY_APERTURE_VIOLATION' tschwinge at gcc dot gnu.org
@ 2022-10-20 10:02 ` cvs-commit at gcc dot gnu.org
  2022-10-20 10:09 ` cvs-commit at gcc dot gnu.org
                   ` (3 subsequent siblings)
  4 siblings, 0 replies; 6+ messages in thread
From: cvs-commit at gcc dot gnu.org @ 2022-10-20 10:02 UTC (permalink / raw)
  To: gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105421

--- Comment #1 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Thomas Schwinge <tschwinge@gcc.gnu.org>:

https://gcc.gnu.org/g:7c55755d4c760de326809636531478fd7419e1e5

commit r13-3404-g7c55755d4c760de326809636531478fd7419e1e5
Author: Julian Brown <julian@codesourcery.com>
Date:   Fri Oct 14 11:06:07 2022 +0000

    amdgcn: Use FLAT addressing for all functions with pointer arguments
[PR105421]

    The GCN backend uses a heuristic to determine whether to use FLAT or
    GLOBAL addressing in a particular (offload) function: namely, if a
    function takes a pointer-to-scalar parameter, it is assumed that the
    pointer may refer to "flat scratch" space, and thus FLAT addressing must
    be used instead of GLOBAL.

    I came up with this heuristic initially whilst working on support for
    moving OpenACC gang-private variables into local-data share (scratch)
    memory. The assumption that only scalar variables would be transformed in
    that way turned out to be wrong.  For example, prior to the next patch in
    the series, Fortran compiler-generated temporary structures were treated
    as gang private and moved to LDS space, typically overflowing the region
    allocated for such variables.  That will no longer happen after that
    patch is applied, but there may be other cases of structs moving to LDS
    space now or in the future that this patch may be needed for.

    2022-10-14  Julian Brown  <julian@codesourcery.com>

            PR target/105421
    gcc/
            * config/gcn/gcn.cc (gcn_detect_incoming_pointer_arg): Any pointer
            argument forces FLAT addressing mode, not just
            pointer-to-non-aggregate.

^ permalink raw reply	[flat|nested] 6+ messages in thread

* [Bug target/105421] GCN offloading, raised '-mgang-private-size': 'HSA_STATUS_ERROR_MEMORY_APERTURE_VIOLATION'
  2022-04-28 13:26 [Bug target/105421] New: GCN offloading, raised '-mgang-private-size': 'HSA_STATUS_ERROR_MEMORY_APERTURE_VIOLATION' tschwinge at gcc dot gnu.org
  2022-10-20 10:02 ` [Bug target/105421] " cvs-commit at gcc dot gnu.org
@ 2022-10-20 10:09 ` cvs-commit at gcc dot gnu.org
  2022-10-21 12:59 ` cvs-commit at gcc dot gnu.org
                   ` (2 subsequent siblings)
  4 siblings, 0 replies; 6+ messages in thread
From: cvs-commit at gcc dot gnu.org @ 2022-10-20 10:09 UTC (permalink / raw)
  To: gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105421

--- Comment #2 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Thomas Schwinge <tschwinge@gcc.gnu.org>:

https://gcc.gnu.org/g:c7ebee2378426eeca425ca5406af213a926f154c

commit r13-3405-gc7ebee2378426eeca425ca5406af213a926f154c
Author: Thomas Schwinge <thomas@codesourcery.com>
Date:   Tue Oct 18 00:13:47 2022 +0200

    Add 'libgomp.oacc-c-c++-common/private-big-1.c' [PR105421]

    After commit r13-3404-g7c55755d4c760de326809636531478fd7419e1e5
    "amdgcn: Use FLAT addressing for all functions with pointer arguments
[PR105421]",
    "big" private data now works for GCN offloading, too.

            PR target/105421
            libgomp/
            * testsuite/libgomp.oacc-c-c++-common/private-big-1.c: New.

^ permalink raw reply	[flat|nested] 6+ messages in thread

* [Bug target/105421] GCN offloading, raised '-mgang-private-size': 'HSA_STATUS_ERROR_MEMORY_APERTURE_VIOLATION'
  2022-04-28 13:26 [Bug target/105421] New: GCN offloading, raised '-mgang-private-size': 'HSA_STATUS_ERROR_MEMORY_APERTURE_VIOLATION' tschwinge at gcc dot gnu.org
  2022-10-20 10:02 ` [Bug target/105421] " cvs-commit at gcc dot gnu.org
  2022-10-20 10:09 ` cvs-commit at gcc dot gnu.org
@ 2022-10-21 12:59 ` cvs-commit at gcc dot gnu.org
  2022-10-21 12:59 ` cvs-commit at gcc dot gnu.org
  2022-10-21 13:03 ` tschwinge at gcc dot gnu.org
  4 siblings, 0 replies; 6+ messages in thread
From: cvs-commit at gcc dot gnu.org @ 2022-10-21 12:59 UTC (permalink / raw)
  To: gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105421

--- Comment #3 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The releases/gcc-12 branch has been updated by Thomas Schwinge
<tschwinge@gcc.gnu.org>:

https://gcc.gnu.org/g:dd2fdf114b59db1b0bfb0de497fc3ab11f034d89

commit r12-8856-gdd2fdf114b59db1b0bfb0de497fc3ab11f034d89
Author: Julian Brown <julian@codesourcery.com>
Date:   Fri Oct 14 11:06:07 2022 +0000

    amdgcn: Use FLAT addressing for all functions with pointer arguments
[PR105421]

    The GCN backend uses a heuristic to determine whether to use FLAT or
    GLOBAL addressing in a particular (offload) function: namely, if a
    function takes a pointer-to-scalar parameter, it is assumed that the
    pointer may refer to "flat scratch" space, and thus FLAT addressing must
    be used instead of GLOBAL.

    I came up with this heuristic initially whilst working on support for
    moving OpenACC gang-private variables into local-data share (scratch)
    memory. The assumption that only scalar variables would be transformed in
    that way turned out to be wrong.  For example, prior to the next patch in
    the series, Fortran compiler-generated temporary structures were treated
    as gang private and moved to LDS space, typically overflowing the region
    allocated for such variables.  That will no longer happen after that
    patch is applied, but there may be other cases of structs moving to LDS
    space now or in the future that this patch may be needed for.

    2022-10-14  Julian Brown  <julian@codesourcery.com>

            PR target/105421
    gcc/
            * config/gcn/gcn.cc (gcn_detect_incoming_pointer_arg): Any pointer
            argument forces FLAT addressing mode, not just
            pointer-to-non-aggregate.

    (cherry picked from commit 7c55755d4c760de326809636531478fd7419e1e5)

^ permalink raw reply	[flat|nested] 6+ messages in thread

* [Bug target/105421] GCN offloading, raised '-mgang-private-size': 'HSA_STATUS_ERROR_MEMORY_APERTURE_VIOLATION'
  2022-04-28 13:26 [Bug target/105421] New: GCN offloading, raised '-mgang-private-size': 'HSA_STATUS_ERROR_MEMORY_APERTURE_VIOLATION' tschwinge at gcc dot gnu.org
                   ` (2 preceding siblings ...)
  2022-10-21 12:59 ` cvs-commit at gcc dot gnu.org
@ 2022-10-21 12:59 ` cvs-commit at gcc dot gnu.org
  2022-10-21 13:03 ` tschwinge at gcc dot gnu.org
  4 siblings, 0 replies; 6+ messages in thread
From: cvs-commit at gcc dot gnu.org @ 2022-10-21 12:59 UTC (permalink / raw)
  To: gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105421

--- Comment #4 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The releases/gcc-12 branch has been updated by Thomas Schwinge
<tschwinge@gcc.gnu.org>:

https://gcc.gnu.org/g:b582496f205c1c3517d8415047fd78321f2c1cdf

commit r12-8857-gb582496f205c1c3517d8415047fd78321f2c1cdf
Author: Thomas Schwinge <thomas@codesourcery.com>
Date:   Tue Oct 18 00:13:47 2022 +0200

    Add 'libgomp.oacc-c-c++-common/private-big-1.c' [PR105421]

    After commit r13-3404-g7c55755d4c760de326809636531478fd7419e1e5
    "amdgcn: Use FLAT addressing for all functions with pointer arguments
[PR105421]",
    "big" private data now works for GCN offloading, too.

            PR target/105421
            libgomp/
            * testsuite/libgomp.oacc-c-c++-common/private-big-1.c: New.

    (cherry picked from commit c7ebee2378426eeca425ca5406af213a926f154c)

^ permalink raw reply	[flat|nested] 6+ messages in thread

* [Bug target/105421] GCN offloading, raised '-mgang-private-size': 'HSA_STATUS_ERROR_MEMORY_APERTURE_VIOLATION'
  2022-04-28 13:26 [Bug target/105421] New: GCN offloading, raised '-mgang-private-size': 'HSA_STATUS_ERROR_MEMORY_APERTURE_VIOLATION' tschwinge at gcc dot gnu.org
                   ` (3 preceding siblings ...)
  2022-10-21 12:59 ` cvs-commit at gcc dot gnu.org
@ 2022-10-21 13:03 ` tschwinge at gcc dot gnu.org
  4 siblings, 0 replies; 6+ messages in thread
From: tschwinge at gcc dot gnu.org @ 2022-10-21 13:03 UTC (permalink / raw)
  To: gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105421

Thomas Schwinge <tschwinge at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|---                         |FIXED

--- Comment #5 from Thomas Schwinge <tschwinge at gcc dot gnu.org> ---
.

^ permalink raw reply	[flat|nested] 6+ messages in thread

end of thread, other threads:[~2022-10-21 13:03 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-04-28 13:26 [Bug target/105421] New: GCN offloading, raised '-mgang-private-size': 'HSA_STATUS_ERROR_MEMORY_APERTURE_VIOLATION' tschwinge at gcc dot gnu.org
2022-10-20 10:02 ` [Bug target/105421] " cvs-commit at gcc dot gnu.org
2022-10-20 10:09 ` cvs-commit at gcc dot gnu.org
2022-10-21 12:59 ` cvs-commit at gcc dot gnu.org
2022-10-21 12:59 ` cvs-commit at gcc dot gnu.org
2022-10-21 13:03 ` tschwinge at gcc dot gnu.org

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).