move most of members to protected section
merge related members into structs
Change-Id: Ief2e092aa5e61ca6f13308f9d9b1937ea6c913b4
Signed-off-by: Mateusz Jablonski <mateusz.jablonski@intel.com>
Include files are now grouped and sorted in following order:
1. Header file of the class the current file implements
2. Project files
3. Third party files
4. Standard library
Change-Id: If31af05652184169f7fee1d7ad08f1b2ed602cf0
Signed-off-by: Filip Hazubski <filip.hazubski@intel.com>
correct add 1 to the current size, gpuRange as gpuRange
only specifies the end address of the pool, not the actual
size, which causes alignment issue of all the offsets of
allocated objects. Also, a page was added in the beginning
of the limited range memory pool to avoid the base address
of it to be 0x0 that is interpreted as invalid address by
heap allocator (This makes the size reduced by pageSize)
Internal 32bit allocator is also initialized in proper way
with corrected base address.
v2: added 'givenMemoryManagerLimimedRangeAllocator' unit
test
v3: adjust size to be freed when DrmMemoryManager instance
is destroyed to 4GB
v4: - defined external 32bit allocator for limited Range
allocation case.
- softpinning object on the correct GPU address
Change-Id: Idaa0206d4133a1476cceb5a48ff8c8528742c76a
Signed-off-by: dongwonk <dongwon.kim@intel.com>
correct mapping of cpu and gpu address in memory allocation
in case of NonSVM. Also, used only aligned address since offset
is already calculated and written to "allocationOffset".
gpuBaseAddress is programmed with 0 instead of base address of
heap because it represents GPU's address space.
v2: add allocationOffset to the aligned address in allocation
data to point to exact starting address of buffer in two
NonSVM allocation unit tests
Change-Id: I32ef512de64a13459b7c132672f837c5cb210ada
Signed-off-by: dongwonk <dongwon.kim@intel.com>
The internal 32bit allocator sometimes need CPU address to access
or store data when it is in reduced address space scenario.
Change-Id: I6c0b3f9703ae3e124249b41ad7d81f03ad93ad17
Signed-off-by: Kai Chen <kai.chen@intel.com>
- remove method allocateGraphicsMemory(size_t size)
- pass allocation type in allocation properties
- set allocation type in allocateGraphicsMemoryInPreferredPool
Change-Id: Ia9296d0ab2f711b7d78aff615cb56b3a246b60ec
Signed-off-by: Mateusz Jablonski <mateusz.jablonski@intel.com>
- make AllocationData a protected structure
- use AllocationProperties instead of AllocationFlags
- refactor methods: allocateGraphicsMemory64kb, allocateGraphicsMemoryForSVM
- call AllocateGraphicsMemoryInPreferredPool in AllocateGraphicsMemory
where there is no host ptr
Change-Id: Ie9ca47b1bccacd00f8486e7d1bf6fb3985e5cb12
Signed-off-by: Mateusz Jablonski <mateusz.jablonski@intel.com>
pass struct with properties to allocate graphics memory methods:
for protected methods use AllocationData
for public methods use AllocationProperties
Change-Id: Ie1c3cb6b5e330bc4adac2ca8b0bf02d30ec76065
Signed-off-by: Mateusz Jablonski <mateusz.jablonski@intel.com>
Code implementation of GPU address allocator for devices with reduced
address space.
Change-Id: Ieb0412c5930fdd71f90741055cf89c0338b01133
Signed-off-by: Kai Chen <kai.chen@intel.com>
Updating files modified in 2018 only. Older files remain with old style
copyright header
Change-Id: Ic99f2e190ad74b4b7f2bd79dd7b9fa5fbe36ec92
Signed-off-by: Artur Harasimiuk <artur.harasimiuk@intel.com>
- extend constructor to take new flag
- extend ExecutionEnvironment createMemoryManager with new flag
- only OsAgnosticMemoryManager changes in this step
Change-Id: I1dae4fd79fe28fd87e42b237600dc216c94b597e
- make createGraphicsAllocationFromSharedHandle and
freeGraphicsMemory more threadsafe - there was race condition
where one thread called PRIME_FD_TO_HANDLE ioctl when the other just
closed the last handle with GEM_CLOSE ioctl. This led to situation
where newly acquired handle from PRIME_FD_TO_HANDLE was already invalid
and used in exec.
- adding mutex for the time of accessing shared handles container
and ioctls (GEM_CLOSE and PRIME_FD_TO_HANDLE) resolves racing problem
Change-Id: I8417a036a1429be8f1ba97e63ebdda2707960564
- createGraphicsAllocationFromSharedHandle was not threadsafe,
instead of reusing BufferObject for a single handle when
multiple threads were creating memory objects from a single VASurface,
new BO could be created and placed in container with BOs for reuse.
This was leading to errors in ioctl calls.
- add lock for following set of operations:
1. find BufferObject with a given handle in container
2. create shared BO when not found
3. add shared BO to container
prevents creating multiple BOs for a single handle
- replace recursive mutex with regular mutex as mutex shouldn't
be locked recursively
Change-Id: I0937e2abf3bf1c672c6d77422d46e441f7216a68
