similar to: [LLVMdev] [PATCH] Delete DyldObj when ELFObjectImage is destroyed

Am 13.06.2017 um 02:05 schrieb Ilia Mirkin: > On Mon, Jun 12, 2017 at 7:57 PM, Roland Scheidegger <sroland at vmware.com> wrote: >> FWIW surely on nv50 you could keep a single mad instruction for umad >> (sad maybe too?). (I'm actually wondering if the hw really can't do >> unfused float multiply+add as a single instruction but I know next to >> nothing

>-----Original Message----- >From: Ben Skeggs <skeggsb at gmail.com> >Sent: Wednesday, November 11, 2020 9:39 PM >To: Ruhl, Michael J <michael.j.ruhl at intel.com> >Cc: Thomas Zimmermann <tzimmermann at suse.de>; bskeggs at redhat.com; >airlied at linux.ie; daniel at ffwll.ch; christian.koenig at amd.com; amd- >gfx at lists.freedesktop.org; nouveau at

On 18/11/14 14:34, Roland Scheidegger wrote: > Am 18.11.2014 um 15:05 schrieb Ilia Mirkin: >> On Tue, Nov 18, 2014 at 8:54 AM, Roland Scheidegger <sroland at vmware.com> wrote: >>> Am 18.11.2014 um 05:03 schrieb Ilia Mirkin: >>>> For values above integer accuracy in floats, val - floor(val) might >>>> actually produce a value greater than 1. For such

On Thu, 12 Nov 2020 at 02:27, Ruhl, Michael J <michael.j.ruhl at intel.com> wrote: > > >-----Original Message----- > >From: Thomas Zimmermann <tzimmermann at suse.de> > >Sent: Wednesday, November 11, 2020 7:08 AM > >To: Ruhl, Michael J <michael.j.ruhl at intel.com>; bskeggs at redhat.com; > >airlied at linux.ie; daniel at ffwll.ch;

This looks like the right idea to me too. It may sound a bit weird to do that per instruction, but d3d11 does that as well. (Some d3d versions just have a global flag basically forbidding or allowing any such fast math optimizations in the assembly, but I'm not actually sure everybody honors that without tesselation...) For 1/9: Reviewed-by: Roland Scheidegger <sroland at vmware.com>

>-----Original Message----- >From: Thomas Zimmermann <tzimmermann at suse.de> >Sent: Wednesday, November 11, 2020 7:08 AM >To: Ruhl, Michael J <michael.j.ruhl at intel.com>; bskeggs at redhat.com; >airlied at linux.ie; daniel at ffwll.ch; christian.koenig at amd.com >Cc: nouveau at lists.freedesktop.org; dri-devel at lists.freedesktop.org; >Maarten Lankhorst

Am 05.09.2012 00:24, schrieb Stephen: > Roland Scheidegger <sroland <at> vmware.com> writes: >> This looks quite similar to something I filed a bug on (12312). Michael >> Liao submitted fixes for this, so I think >> if you change it to >> %16 = fcmp ogt <4 x float> %15, %cr >> %17 = sext <4 x i1> %16 to <4 x i32> >> %18 =

Roland Scheidegger <sroland <at> vmware.com> writes: > This looks quite similar to something I filed a bug on (12312). Michael > Liao submitted fixes for this, so I think > if you change it to > %16 = fcmp ogt <4 x float> %15, %cr > %17 = sext <4 x i1> %16 to <4 x i32> > %18 = bitcast <4 x i32> %17 to i128 > %19 = icmp ne i128 %18, 0

On Tue, May 18, 2010 at 7:04 PM, Roland Scheidegger <sroland at vmware.com> wrote: > Hi, > > I plan to merge the gallium-msaa branch to master soon. > It's actually a bit of a misnomer since the conceptually more important > changes in there are about blits... > > Here's a short summary what this is about: > blits now operate on resources, not surfaces

Hi Am 10.11.20 um 16:27 schrieb Ruhl, Michael J: > > >> -----Original Message----- >> From: Thomas Zimmermann <tzimmermann at suse.de> >> Sent: Tuesday, November 10, 2020 8:37 AM >> To: bskeggs at redhat.com; airlied at linux.ie; daniel at ffwll.ch; Ruhl, Michael J >> <michael.j.ruhl at intel.com>; christian.koenig at amd.com >> Cc: nouveau

> On Nov 24, 2020, at 06:38, Thomas Zimmermann <tzimmermann at suse.de> wrote: > > Using struct drm_device.pdev is deprecated. Convert vmwgfx to struct > drm_device.dev. No functional changes. > > Signed-off-by: Thomas Zimmermann <tzimmermann at suse.de> > Cc: Roland Scheidegger <sroland at vmware.com> > --- > drivers/gpu/drm/vmwgfx/vmwgfx_cmdbuf.c |

On Tue, Nov 18, 2014 at 8:54 AM, Roland Scheidegger <sroland at vmware.com> wrote: > Am 18.11.2014 um 05:03 schrieb Ilia Mirkin: >> For values above integer accuracy in floats, val - floor(val) might >> actually produce a value greater than 1. For such large floats, it's >> reasonable to be imprecise, but it's unreasonable for FRC to return a >> value that

> On Dec 2, 2020, at 09:27, Thomas Zimmermann <tzimmermann at suse.de> wrote: > > Hi > > Am 02.12.20 um 09:01 schrieb Thomas Zimmermann: >> Hi >> Am 30.11.20 um 21:59 schrieb Zack Rusin: >>> >>> >>>> On Nov 24, 2020, at 06:38, Thomas Zimmermann <tzimmermann at suse.de> wrote: >>>> >>>> Using struct

Am 13.06.2017 um 01:57 schrieb Roland Scheidegger: > This looks like the right idea to me too. It may sound a bit weird to do > that per instruction, but d3d11 does that as well. (Some d3d versions > just have a global flag basically forbidding or allowing any such fast > math optimizations in the assembly, but I'm not actually sure everybody > honors that without

>-----Original Message----- >From: Thomas Zimmermann <tzimmermann at suse.de> >Sent: Tuesday, November 10, 2020 8:37 AM >To: bskeggs at redhat.com; airlied at linux.ie; daniel at ffwll.ch; Ruhl, Michael J ><michael.j.ruhl at intel.com>; christian.koenig at amd.com >Cc: nouveau at lists.freedesktop.org; dri-devel at lists.freedesktop.org; Thomas >Zimmermann

The value of struct drm_device.ttm.type_vram can become -1 for unknown types of memory (see nouveau_ttm_init()). This leads to an out-of-bounds error when accessing struct nvif_mmu.type[]: [ 18.304116] ================================================================== [ 18.311649] BUG: KASAN: slab-out-of-bounds in nouveau_ttm_io_mem_reserve+0x17a/0x7e0 [nouveau] [ 18.320415] Read of

Am 18.11.2014 um 15:05 schrieb Ilia Mirkin: > On Tue, Nov 18, 2014 at 8:54 AM, Roland Scheidegger <sroland at vmware.com> wrote: >> Am 18.11.2014 um 05:03 schrieb Ilia Mirkin: >>> For values above integer accuracy in floats, val - floor(val) might >>> actually produce a value greater than 1. For such large floats, it's >>> reasonable to be imprecise,

On Thu, Dec 03, 2020 at 03:06:20AM +0000, Zack Rusin wrote: > > > > On Dec 2, 2020, at 11:03, Daniel Vetter <daniel at ffwll.ch> wrote: > > > > On Wed, Dec 2, 2020 at 4:37 PM Zack Rusin <zackr at vmware.com> wrote: > >> > >> > >> > >>> On Dec 2, 2020, at 09:27, Thomas Zimmermann <tzimmermann at suse.de> wrote:

Oh right. I think the NVIDIA blob executes those steps conditionally based on the upper bits not being 0x7ff (== infinity/nan). I should do the same thing here. [FWIW I was able to test the nv50 code last night and that one's a total fail for rcp/rsq... will need to port that over to my nvc0 and debug there.] On Mon, Feb 23, 2015 at 8:24 AM, Roland Scheidegger <sroland at vmware.com>

On Mon, Jun 12, 2017 at 7:57 PM, Roland Scheidegger <sroland at vmware.com> wrote: > FWIW surely on nv50 you could keep a single mad instruction for umad > (sad maybe too?). (I'm actually wondering if the hw really can't do > unfused float multiply+add as a single instruction but I know next to > nothing about nvidia hw...) The compiler should reassociate a mul + add