[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAJAsdNi7t30iJ9YgmgpeM_7czAK3QwuBS7wVOxV1fk7VSQVDMg@mail.gmail.com>
Date: Sun, 6 Oct 2013 21:25:14 +0100
From: Dániel Bali <balijanosdaniel@...il.com>
To: john-dev@...ts.openwall.com
Subject: Re: AMD GPU documentation (was: Daniel's weekly report #15)
Hello Alexander, Lukas,
2013/10/3 Lukas Odzioba <lukas.odzioba@...il.com>
> I am affraid that we will still have problems with pathing binaries
> unless we change approach.
> I have two ideas at the moment:
> 1) can you split binary on parts using definitions in this header:
>
> http://www.multi2sim.org/svn/multi2sim/trunk/src/arch/southern-islands/asm/bin-file.h
>
> I am curious how much of that match the real format.
Since your message the file was moved to
http://www.multi2sim.org/svn/multi2sim/tags/multi2sim-4.2/src/arch/southern-islands/asm/bin-file.h
How do you mean to split the binary? Could you give an example?
>
> 2) Since CAL has separated compilation and linking phases, maybe we
> can somehow do something like pathing between those phases.
> You probably saw this:
>
> http://developer.amd.com/wordpress/media/2012/10/AMD_CAL_Programming_Guide_v2.0.pdf
>
> It looks like program is stored in CALobject, but I can't find a its
> definition anywhere.
> Also If I remember right realhet used CAL for some reason.
In section 2.2.1 (Compiling and linking) it uses IL assembly code. Isn't
this what we are trying to skip when writing GCN asm?
2013/10/4 Solar Designer <solar@...nwall.com>
> BTW, speaking of AMD documentation on Southern Islands GPUs, these PDFs
> might be relevant to the project as well:
>
> http://www.x.org/docs/AMD/si_programming_guide_v2.pdf
> http://www.x.org/docs/AMD/SI_3D_registers.pdf
>
> In particular, page 165+ in SI_3D_registers.pdf describes "Shared
> Program Registers", which includes things such as "Number of VGPRs,
> granularity 4. Range is from 0-63 allocating 4, 8, 12, ... 256" - a
> certain 6-bit value at a certain address (memory-mapped register?)
> This might answer, negatively, my question on whether we can go beyond
> 256 VGPRs for a single work-item.
>
Oh, I see these were just released last week, very nice. I didn't know the
granularity is 4 here. I tried using 0xFF for VGPR and SGPR values and the
kernel just failed, so later I always used 0x20 which seems to be an error,
since the limit for SPGRs is 15. Maybe if I change this value the kernel
won't fail?
I'll try to read into all of these documents in my free time.
Regards,
Daniel
Content of type "text/html" skipped
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
