gem5 - gem5

Age	Commit message (Collapse)	Author
2018-05-16	style: fix amd license and style issues	Tony Gutierrez
	Change-Id: I26136fb49f743c4a597f8021cfd27f78897267b5 Reviewed-on: https://gem5-review.googlesource.com/10463 Reviewed-by: Jason Lowe-Power <jason@lowepower.com> Maintainer: Anthony Gutierrez <anthony.gutierrez@amd.com>
2017-12-04	misc: Rename misc.(hh\|cc) to logging.(hh\|cc)	Gabe Black
	These files aren't a collection of miscellaneous stuff, they're the definition of the Logger interface, and a few utility macros for calling into that interface (panic, warn, etc.). Change-Id: I84267ac3f45896a83c0ef027f8f19c5e9a5667d1 Reviewed-on: https://gem5-review.googlesource.com/6226 Reviewed-by: Brandon Potter <Brandon.Potter@amd.com> Maintainer: Gabe Black <gabeblack@google.com>
2016-10-26	gpu-compute: add gpu_isa.hh to switch hdrs, add GPUISA to WF	Tony Gutierrez
	the GPUISA class is meant to encapsulate any ISA-specific behavior - special register accesses, isa-specific WF/kernel state, etc. - in a generic enough way so that it may be used in ISA-agnostic code. gpu-compute: use the GPUISA object to advance the PC the GPU model treats the PC as a pointer to individual instruction objects - which are store in a contiguous array - and not a byte address to be fetched from the real memory system. this is ok for HSAIL because all instructions are considered by the model to be the same size. in machine ISA, however, instructions may be 32b or 64b, and branches are calculated by advancing the PC by the number of words (4 byte chunks) it needs to advance in the real instruction stream. because of this there is a mismatch between the PC we use to index into the instruction array, and the actual byte address PC the ISA expects. here we move the PC advance calculation to the ISA so that differences in the instrucion sizes may be accounted for in generic way.
2016-10-04	gpu-compute: Added method to compute the actual workgroup size	Alexandru Dutu
	This patch adds a method to the Wavefront class to compute the actual workgroup size. This can be different from the maximum workgroup size specified when launching the kernel through the NDRange object. Current solution is still not optimal, as we are computing these for each wavefront and the dispatcher also needs to have this information and can't actually call Wavefront::computeActuallWgSz before the wavefronts are being created. A long term solution would be to have a Workgroup class that deals with all these details.
2016-09-16	gpu-compute: Adding context serialization methods to Wavefront	Alexandru Dutu
	This patch adds methods to serialize the context of a particular wavefront to the simulated system memory. Context serialization is used when a wavefront is preempeted (i.e. context switch).
2016-09-16	gpu-compute: Refactoring Wavefront::dynWaveId	Alexandru Dutu

2016-09-16	gpu-compute: Changing reconvergenceStack type	Alexandru Dutu
	std::stack has no iterators, therefore the reconvergence stack can't be iterated without poping elements off. We will be using std::list instead to be able to iterate for saving and restoring purposes.
2016-09-16	gpu-compute: Adding ioctl for HW context size	Alexandru Dutu
	Adding runtime support for determining the memory required by a SIMD engine when executing a particular wavefront.
2016-09-16	gpu-compute: Wavefront refactoring	Alexandru Dutu
	Renaming members of the Wavefront class in accordance with the style guide.
2016-06-09	gpu-compute: parametrize Wavefront size	jkalamat
	Eliminate the VSZ constant that defined the Wavefront size (in numbers of work items); replaced it with a parameter in the GPU.py configuration script. Changed all data structures dependent on the Wavefront size to be dynamically sized. Legal values of Wavefront size are 16, 32, 64 for now and checked at initialization time.
2016-01-19	gpu-compute: AMD's baseline GPU model	Tony Gutierrez