search for: t124

On Sat, Feb 1, 2014 at 1:16 PM, Alexandre Courbot <acourbot at nvidia.com> wrote: > GK20A's timer is directly attached to the system timer and cannot be > calibrated. Skip the calibration phase on that chip since the > corresponding registers do not exist. Just a curiosity: What timer resolution does the HW initialise at? > > Signed-off-by: Alexandre Courbot <acourbot

...nvidia.com> wrote: >> GK20A's timer is directly attached to the system timer and cannot be >> calibrated. Skip the calibration phase on that chip since the >> corresponding registers do not exist. > Just a curiosity: What timer resolution does the HW initialise at? On T124 the timer input is the oscillator clock, which depending on the device can run between 12 and 48Mhz (IIUC).

...AM are handled by the VRAM manager, which requires a nouveau_ram instance in the FB. Actually the FB also seems to assume the presence of a dedicated video RAM. So while I agree that getting rid of VRAM altogether would be the most logical solution, I have not found a way to do so for the moment. T124's GPU actually sees the same physical address space as the CPU, so memory management should be simplified thanks to that (you could enable the SMMU and make things more interesting/complex, but for now it seems untimely to even consider doing so). Actually even the concept of a GART is not need...

Am Samstag, den 01.02.2014, 18:28 -0500 schrieb Ilia Mirkin: > On Sat, Feb 1, 2014 at 8:40 AM, Lucas Stach <dev at lynxeye.de> wrote: > > Am Samstag, den 01.02.2014, 12:16 +0900 schrieb Alexandre Courbot: > >> Add a clumsy-but-working FB support for GK20A. This chip only uses system > >> memory, so we allocate a big chunk using CMA and let the existing memory >

.... Split node result: t123: v64i64 = BUILD_VECTOR undef:i64, undef:i64, undef:i64, undef:i64, undef:i64, undef:i64, undef:i64, undef:i64, undef:i64, undef:i64, undef:i64, undef:i64, undef:i64, undef:i64, undef:i64, undef:i64, undef:i64, undef:i64, undef:i64, undef:... Split node result: t124: v32i64 = BUILD_VECTOR undef:i64, undef:i64, undef:i64, undef:i64, undef:i64, undef:i64, undef:i64, undef:i64, undef:i64, undef:i64, undef:i64, undef:i64, undef:i64, undef:i64, undef:i64, undef:i64, undef:i64, undef:i64, undef:i64, undef:... Split node result: t125: v16i64 = BUILD_VECTOR un...

...e result: t123: v64i64 = BUILD_VECTOR undef:i64, undef:i64, undef:i64, > undef:i64, undef:i64, undef:i64, undef:i64, undef:i64, undef:i64, undef:i64, undef:i64, > undef:i64, undef:i64, undef:i64, undef:i64, undef:i64, undef:i64, undef:i64, undef:i64, > undef:... > Split node result: t124: v32i64 = BUILD_VECTOR undef:i64, undef:i64, undef:i64, > undef:i64, undef:i64, undef:i64, undef:i64, undef:i64, undef:i64, undef:i64, undef:i64, > undef:i64, undef:i64, undef:i64, undef:i64, undef:i64, undef:i64, undef:i64, undef:i64, > undef:... > Split node result: t125: v16i64 =...

The T124 generation of Tegra GPUs uses the Kepler architecture and can thus be driven by Nouveau. However, they are declared as platform devices using the Device Tree, and Nouveau has a very strong dependency on PCI. This patch makes Nouveau core able to handle platform devices as well as PCI devices. Comm...

Hello. Will, thanks a lot for pointing me to the MaskedGatherSDNode and mgatherv4i32. I have to say that the definition of the "multiclass avx512_gather" from lib/Target/X86/X86InstrAVX512.td is difficult to follow and I prefer not to use it. I currently have some serious problems with TableGen - it gives an assertion failure:

Hello everyone, GK20A is the Kepler-based GPU used in the upcoming Tegra K1 chips. The following patches perform architectural changes to Nouveau that are necessary to support non-PCI GPUs and add initial support for GK20A. Although the support is still very basic and more user-space changes will be needed to make the full graphics stack run on top of it, we were able to successfully open