SYSTEM AND METHOD FOR USING VIRTUAL VECTOR REGISTER FILES

• US 20170371654A1
• Filed: 06/23/2016
• Published: 12/28/2017
• Est. Priority Date: 06/23/2016
• Status: Active Application

• Current Assignee: Advanced Micro Devices, Inc., ATI Technologies ULC (Advanced Micro Devices, Inc.)
• Original Assignee: Advanced Micro Devices, Inc., ATI Technologies ULC (Advanced Micro Devices, Inc.)
• Inventors: Bajic, Ljubisa, Mantor, Michael, Gilani, Syed Zohaib M., Koduri, Rajabali M.
• Application Number:
  US15/191,339
• Publication Number:
  US 20170371654A1
• Time in Patent Office: Days
• CPC Class Codes: G06F 9/3012 Organisation of register space, e.g. banked or distributed register file
• CPC Class Codes: G06F 9/30123 according to context, e.g. thread buffers
• CPC Class Codes: G06F 9/384 Register renaming
• CPC Class Codes: G06F 9/3851 from multiple instruction streams, e.g. multistreaming
• CPC Class Codes: G06F 9/3887 controlled by a single instruction for multiple data lanes [SIMD]

Abstract

Described is a system and method for using virtual vector register files. In particular, a graphics processor includes a logic unit, a virtual vector register file coupled to the logic unit, a vector register backing store coupled to the virtual vector register file, and a virtual vector register file controller coupled to the virtual vector register file. The virtual vector register file includes a N deep vector register file and a M deep vector register file, where N is less than M. The virtual vector register file controller performing eviction and allocation between the N deep vector register file, the M deep vector register file and the vector register backing store dependent on at least access requests for certain vector registers.

Claims

1. A graphics processor, comprising:

a logic unit;

a virtual vector register file coupled to the logic unit, the virtual vector register file including a N deep vector register file and a M deep vector register file, wherein N is less than M;

a vector register backing store coupled to the virtual vector register file; and

a virtual vector register file controller coupled to the virtual vector register file, wherein eviction/allocation between the N deep vector register file, the M deep vector register file and the vector register backing store is dependent on at least access requests for certain vector registers.

2. The graphics processor of claim 1, wherein the virtual vector register file controller includes:

a vector register re-mapping table; and

an allocator/de-allocator module coupled to the vector register re-mapping table and to the virtual vector register file and the vector register backing store.

3. The graphics processor of claim 2, wherein the vector register re-mapping table is indexed by a virtual vector register number, with each table entry storing a pointer to the vector register backing store or a corresponding physical hardware vector register file in the virtual vector register file.

4. The graphics processor of claim 3, wherein each table entry includes a resident bit that signifies whether a vector register is physically present in the virtual vector register file, an accessed bit to enable usage of replacement algorithms for vector register allocation/de-allocation, and a dirty bit to optimize write-back to a next higher level of vector register file hierarchy.

6. The graphics processor of claim 2, wherein the allocator/de-allocator uses a plurality of lists to track candidates for eviction and track vector register files that are unallocated for eviction/allocation analysis.

8. The graphics processor of claim 1, wherein the virtual vector register file controller presents a logical view to external components that all vector registers are physically implemented in hardware.

7. The graphics processor of claim 7, wherein the allocator/de-allocator uses a list to track vector register file ownership by thread for eviction/allocation analysis.

9. A method for using a virtual vector register file in a graphics processor, the method comprising:

determining if a requested vector register is present in a corresponding physical hardware vector register file in a virtual vector register file, wherein the virtual vector register file includes a N deep vector register file and a M deep vector register file, N being less than M;

initiating, by a virtual vector register file controller, a swapping process to bring the requested vector register into the corresponding physical hardware vector register file; and

sending a notification that the required vector register is now present.

10. The method for using a virtual vector register file in a graphics processor of claim 9, further comprising:

indexing a vector register re-mapping table to determine if the requested vector register is in the corresponding physical hardware vector register file in a virtual vector register file;

reviewing, by an allocator/de-allocator module, a plurality of lists to bring the requested vector register into the corresponding physical hardware vector register file.

11. The method for using a virtual vector register file in a graphics processor of claim 10, wherein the vector register re-mapping table is indexed by a virtual vector register number, with each table entry storing a pointer to the vector register backing store or a corresponding physical hardware vector register file in the virtual vector register file.

12. The method for using a virtual vector register file in a graphics processor of claim 11, wherein each table entry includes a resident bit that signifies whether a vector register is physically present in the virtual vector register file, an accessed bit to enable usage of replacement algorithms for register allocation/de-allocation, and a dirty bit to optimize write-back to a next higher level of vector register file hierarchy.

13. The method for using a virtual vector register file in a graphics processor of claim 10, wherein the plurality of lists track candidates for eviction and track vector register files that are unallocated for eviction/allocation analysis.

14. The method for using a virtual vector register file in a graphics processor of claim 10, wherein the allocator/de-allocator uses a list to track vector register file ownership by thread for eviction/allocation analysis.

15. The method for using a virtual vector register file in a graphics processor of claim 9, wherein the virtual vector register file controller presents a logical view to external components that all vector registers are physically implemented in hardware.

16. A non-transitory computer readable medium including instructions which when executed in a graphics processor cause the graphics processor to execute a method for using virtual vector register files, the method comprising the steps of:

determining if a requested vector register is present in a corresponding physical hardware vector register file in a virtual vector register file, wherein the virtual vector register file includes a N deep vector register file and a M deep vector register file, N being less than M;

initiating, by a virtual vector register file controller, a swapping process to bring the requested vector register into the corresponding physical hardware vector register file; and

sending a notification that the required vector register is now present.

17. The non-transitory computer readable medium of claim 16, further comprising:

indexing a vector register re-mapping table to determine if the requested vector register is in the corresponding physical hardware vector register file in a virtual vector register file;

reviewing, by an allocator/de-allocator module, a plurality of lists to bring the requested vector register into the corresponding physical hardware vector register file.

18. The non-transitory computer readable medium of claim 17, wherein the vector register re-mapping table is indexed by a virtual vector register number, with each table entry storing a pointer to the vector register backing store or a corresponding physical hardware vector register file in the virtual vector register file.

19. The non-transitory computer readable medium of claim 18, wherein each table entry includes a resident bit that signifies whether a vector register is physically present in the virtual vector register file, an accessed bit to enable usage of replacement algorithms for vector register allocation/de-allocation, and a dirty bit to optimize write-back to a next higher level of vector register file hierarchy.

20. The non-transitory computer readable medium of claim 17, wherein the plurality of lists track candidates for eviction and track vector register files that are unallocated for eviction/allocation analysis.

21. The non-transitory computer readable medium of claim 17, wherein the allocator/de-allocator uses a list to track vector register file ownership by thread for eviction/allocation analysis.

22. The non-transitory computer readable medium of claim 16, wherein the virtual vector register file controller presents a logical view to external components that all vector registers are physically implemented in hardware.