Графік комітів

6 Коміти

Автор SHA1 Повідомлення Дата
Harish Kasiviswanathan 9cf5049f77 Revert "Topology, memory allocation, cleanup issue for gGPU"
This reverts commit 0dc4437390.

Change-Id: I92a4ed91bf566259916d1a96207e1fe9a6099c31
Signed-off-by: Harish Kasiviswanathan <Harish.Kasiviswanathan@amd.com>


[ROCm/ROCR-Runtime commit: 3e9773ff2c]
2015-09-21 10:47:30 -04:00
Harish Kasiviswanathan 0dc4437390 Topology, memory allocation, cleanup issue for gGPU
Patch submitted by Besar Wicaksono

1. Bug on detecting local memory size interpreted as 32 bit value
instead of 64. The bug causes thunk to go into an infinite loop trying
to reserve virtual address range for dgpu system memory.
2. SIMD count in the node property is 0. Runtime use this attribute to
find a gpu device.
	Regarding other attributes of intel+tonga topology, Harish started a
	discussion on August iirc, could you please share an update ?
	This would help me progress with more tests such as scratch memory,
	which require the scratch aperture information in order to construct a
	buffer srd in gpuvm space.
3. Bug on releasing memory via fmm_release, where no actual release is
being done. The vm_object can't be found because the memory size does
not match due to the allocation padded the size with 32KB.
4. Pointer arithmetic on vm_area allocation/release. The value of
vm_area_t::end seems to be interpreted inconsistently whether it is
(start + size  -1) or (start + size).
	One example of potential issue I see is the logic could report
	larger size of the hole in the vm area list.
5. Resource cleanup on multiple library load/unload within a single
process.
	- Any memory allocation on subsequent library load will result
	an error "va above limit". To my understanding this is due to
	the reserved memory for the system memory not being released on unload.
	- The static variable events_page needs to be invalidated
	appropriately on library unload so the next load could
	reinitialize it.
6. Could you please update if AQL queue is ready to test with the stg
kfd/kmt ?
7. The system memory allocation with size larger than 32KB seems to be
padded by an extra 32KB. I was wondering if we could remove this
overhead.

Change-Id: I039988d36637525089c7569dc3b77e58750e2121


[ROCm/ROCR-Runtime commit: ee08f537a7]
2015-09-15 13:15:04 -04:00
Oded Gabbay 22136281cb Move from direct call to kfd_ioctl to wrapping kmtIoctl
Signed-off-by: Oded Gabbay <oded.gabbay@amd.com>


[ROCm/ROCR-Runtime commit: 94c0329fc4]
2014-12-29 15:37:42 +02:00
Alexey Skidanov cdfe250500 Add exclusive trace access
Signed-off-by: Alexey Skidanov <Alexey.Skidanov@amd.com>


[ROCm/ROCR-Runtime commit: 0ecaa96523]
2014-12-29 10:13:32 +02:00
Alexey Skidanov b9a373de9d Add flat memory manager module
Signed-off-by: Alexey Skidanov <Alexey.Skidanov@amd.com>
Signed-off-by: Oded Gabbay <oded.gabbay@amd.com>


[ROCm/ROCR-Runtime commit: 1905152a33]
2014-07-29 11:21:10 +03:00
Oded Gabbay a91aa132aa Add skeleton driver which supports open and close
Signed-off-by: Oded Gabbay <oded.gabbay@amd.com>


[ROCm/ROCR-Runtime commit: 85ba9efa18]
2014-07-29 11:16:00 +03:00