I hope and expect the nova and vgpu_mgr efforts to ultimately converge.
First, for the fw ABI debacle: yes, it is unfortunate that we still don't
have a stable ABI from GSP. We /are/ working on it, though there isn't
anything to show, yet. FWIW, I expect the end result will be a much
simpler i
ndle
The Fermi LINKED_TSC case was the one we were least sure of from code
inspection. Hopefully you can determine that case empirically?
Sorry I'm not more help here.
- Andy
> Thanks again for the info!
>
> -ilia
>
> On Wed, Mar 7, 2018 at 3:21 PM, Andy Ritger wro
Hi Ilia.
It looks like there is a hardware bug on Fermi and Kepler where TLD
unconditionally uses the sampler from slot 0. This is supposedly fixed
in Maxwell. What I could find internally suggests the bug wasn't present
on Tesla, but let me know if your observations contradict that.
The only
Hi Martin,
I was asked to clarify a few things:
(1) Are all the user reports of loud fans on Fermi-era GPUs?
(2) When the VBIOS POSTs the card, it loads initial ucode onto the Falcon
processor (PMU), which will do basic fan management on its own. We call this
init ucode "IFR" (Init From ROM).
Thanks, Martin. I'll try to follow up on this next week and get you an answer.
What GPUs have you observed this on?
On Fri, Sep 18, 2015 at 11:13:53PM +0300, Martin Peres wrote:
> Hello,
>
> We recently reverse engineered PWM-based voltage management but found an
> odity in the input clock fr
A while ago, Ben Skeggs asked for some better documentation on EVO.
Sorry it took a while, but here are the EVO class header files for NV50
through GM204:
ftp://download.nvidia.com/open-gpu-doc/Display-Class-Methods/1/
These header files define the method interface to the various EVO
chann
On Mon, Dec 15, 2014 at 07:40:32AM +1000, Ben Skeggs wrote:
> On Sat, Dec 13, 2014 at 6:42 PM, Andy Ritger wrote:
> > On Wed, Dec 10, 2014 at 07:46:16AM +1000, Ben Skeggs wrote:
> >> On Wed, Dec 10, 2014 at 7:36 AM, Ben Skeggs wrote:
> >> > On Wed, Dec 10, 2014
On Wed, Dec 10, 2014 at 07:46:16AM +1000, Ben Skeggs wrote:
> On Wed, Dec 10, 2014 at 7:36 AM, Ben Skeggs wrote:
> > On Wed, Dec 10, 2014 at 4:26 AM, Andy Ritger wrote:
> >> Hi,
> > Hey Andy,
> >
> >>
> >> The VBIOS on GM20x GPUs uses a slightly
Hi,
The VBIOS on GM20x GPUs uses a slightly updated version of the DCB.
I've posted an updated DCB spec here:
ftp://download.nvidia.com/open-gpu-doc/DCB/2/DCB-4.x-Specification.html
You can diff it against the previous version:
ftp://download.nvidia.com/open-gpu-doc/DCB/1/DCB-4.0-Specification.
Reviewed-by: Andy Ritger
On Sun, Nov 30, 2014 at 12:56:18PM -0500, Ilia Mirkin wrote:
> Indications are that no GF116's actually have a copy engine there, but
> actually have the decompression engine. This engine can be made to do
> copies, but that should be done separately.
&g
On Wed, Nov 26, 2014 at 02:18:25AM +0100, Marcin Kościelnicki wrote:
[...]
> >>http://envytools.readthedocs.org/en/latest/hw/gpu.html#fermi-kepler-maxwell-family
> >
> >I don't see the 0x650 register values on that page. Maybe I'm not
> >looking at the right place?
>
> The table at the bottom, CE
On Tue, Nov 25, 2014 at 10:57:44AM -0500, Ilia Mirkin wrote:
> On Mon, Nov 24, 2014 at 8:33 PM, Andy Ritger wrote:
> > On Fri, Nov 21, 2014 at 01:39:55AM -0500, Ilia Mirkin wrote:
> >> On Fri, Nov 21, 2014 at 1:16 AM, Andy Ritger wrote:
> >> > Hi Ilia,
> >>
On Fri, Nov 21, 2014 at 01:39:55AM -0500, Ilia Mirkin wrote:
> On Fri, Nov 21, 2014 at 1:16 AM, Andy Ritger wrote:
> > Hi Ilia,
> >
> > Actually 0x90b8 is different than copy engine. I'm not very familiar
> > with it, but 0x90b8 is an engine for performing
Hi Ilia,
Actually 0x90b8 is different than copy engine. I'm not very familiar
with it, but 0x90b8 is an engine for performing LZO decompression as
part of performing the copy. It has a variety of limitations (e.g.,
cannot handle blocklinear format), and was only in a few Fermi chips,
as I unders
On Sat, Sep 27, 2014 at 10:13:43AM +1000, Ben Skeggs wrote:
> On Sat, Sep 27, 2014 at 3:19 AM, Andy Ritger wrote:
> >
> > Hi, all.
> Hey Andy,
>
> >
> > Below is a link to a brief document describing some changes in NVIDIA
> > Falcon processors ("fuc&q
Hi, all.
Below is a link to a brief document describing some changes in NVIDIA
Falcon processors ("fuc", in Nouveau-speak, IIUC) that happened in
Maxwell: certain aspects of the chip will only be available to Falcon
firmware images signed by NVIDIA. So far, the set of restricted things
is pretty
Hi Ilia. I'll take a look and see what I can find out.
Thanks,
- Andy
On Wed, Apr 23, 2014 at 05:03:17PM -0700, Ilia Mirkin wrote:
> On Wed, Apr 23, 2014 at 6:22 PM, Ilia Mirkin wrote:
> > Hello,
> >
> > I've been trying to add ARB_sample_shading support to nouveau, and am
> > being defeated b
Sorry for the very slow response to this, Ilia.
For the specific error you mentioned: the error code
0x51 is "ErrorSrcLineExceedsPitch", and error code 0x53 is
"ErrorDstLineExceedsPitch". It looks like class 0x9039 will generate
those errors under the following conditions:
if ((NV9039_LAUN
g uninitialized
data in the unused bits.
I hope that helps,
- Andy Ritger
On Thu, Feb 27, 2014 at 11:37:40PM -0800, Ilia Mirkin wrote:
> Hello,
>
> I've recently run into an unknown bit in Tesla shaders, and was hoping
> you could shed some light on it. I believe they're rel
Hi Nouveau developers,
We've posted a short document about disabling display underflow reporting
on GK104, which is needed due to an incorrect setting in some production
GK104 VBIOSes:
ftp://download.nvidia.com/open-gpu-doc/gk104-disable-underflow-reporting/1/gk104-disable-underflow-reporting.txt
Hi Ben,
At XDC you asked about the architecture field in NV_PMC_BOOT_0, and how
to correctly determine the GPU architecture.
It looks like Nouveau is getting the architecture from bits 20-27
in NV_PMC_BOOT_0 (though masking off bits 20-23). For >= NV10, the
architecture field in NV_PMC_BOOT_0 i
On Wed, Sep 25, 2013 at 12:46:12AM -0700, Marcin Kościelnicki wrote:
> > Does Nouveau reimplement Falcon microcode due to particular deficiencies
> > in NVIDIA's microcode, or because you couldn't get permission in the past
> > to redistribute the firmware extracted from NVIDIA's proprietary driver
On Tue, Sep 24, 2013 at 12:43:46PM -0700, Dave Airlie wrote:
...
>
> Hey Andy,
>
> this is great news,
>
> I suppose the question I have is there any known upfront limits on
> what you can release or is it going to be a per-request type thing?
Hi Dave.
I think we're going to have to deal with
On Tue, Sep 24, 2013 at 12:12:02AM -0700, Maarten Lankhorst wrote:
> Hey,
>
> Op 24-09-13 06:44, Andy Ritger schreef:
> > Hi Nouveau developers,
> >
> > NVIDIA is releasing public documentation on certain aspects of our GPUs,
> > with the intent to address are
-...@nvidia.com. I can't promise we'll be able to answer
everything, but we'll provide best-effort in areas where we are able.
Thanks,
- Andy Ritger
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau
25 matches
Mail list logo
