<html>
<head>
<base href="https://bugs.freedesktop.org/" />
</head>
<body>
<p>
<div>
<b><a class="bz_bug_link
bz_status_NEW "
title="NEW - Add FP64 support to the i965 shader backends"
href="https://bugs.freedesktop.org/show_bug.cgi?id=92760#c9">Comment # 9</a>
on <a class="bz_bug_link
bz_status_NEW "
title="NEW - Add FP64 support to the i965 shader backends"
href="https://bugs.freedesktop.org/show_bug.cgi?id=92760">bug 92760</a>
from <span class="vcard"><a class="email" href="mailto:itoral@igalia.com" title="Iago Toral <itoral@igalia.com>"> <span class="fn">Iago Toral</span></a>
</span></b>
<pre>(In reply to Connor Abbott from <a href="show_bug.cgi?id=92760#c8">comment #8</a>)
<span class="quote">> (In reply to Iago Toral from <a href="show_bug.cgi?id=92760#c6">comment #6</a>)
> > While having a look at the patches I noticed a couple of obvious bugs that I
> > thought would break things outside fp64, so I ran piglit and found that this
> > in fact breaks a ton of things on my IVB laptop. A run of shader.py (without
> > fp64 tests) gives:
> >
> > [14079/14079] skip: 7034, pass: 5104, fail: 1046, crash: 895 \
> >
> > including a handful GPU hangs :(
> >
> > I have been fixing a lot of these today, mostly small things here and there
> > and now we are at:
> >
> > [14079/14079] skip: 6973, pass: 7043, fail: 46, crash: 3
> >
> > This means a total of 48 regressions compared to master excluding fp64
> > functionality (and only for shader.py). These regressions include 9 GPU
> > hangs.
> >
> > In case you want to have a look, I have uploaded my fixes to this branch
> > (rebased against current master too):
> > <a href="https://github.com/Igalia/mesa/commits/connor-i965-fp64-v3-rebased">https://github.com/Igalia/mesa/commits/connor-i965-fp64-v3-rebased</a>
> >
> > I think we should focus on tracking and fixing the remaining regressions
> > before moving on to doing actual fp64 stuff.
> >
> > BTW, right now we have things like nir_type_float and nir_type_float32, or
> > nit_type_int and nir_type_int32...there is a number of patches in your
> > branch that changes some uses of basic types by the bit-sized versions, and
> > I had to add a few more in my branch to fix a good number of crashes and
> > problems since the driver has some code paths that expect a bit-sized type
> > in any case (in fact, they have assertions for this). Why don't we just drop
> > the types that don't have the bit-size information completely? As it is now
> > I think they only cause confusion and bugs.
>
> No... in fact, the unsized types were kind of the entire point of Jason's
> original proposal that I took as the basis of my implementation. A type of
> nir_type_float means "this instruction can take any bit-width, but it has to
> match with any other source/destination of this instruction that is
> nir_type_float as well," sort of like how an input_size/output_size of 0
> allows to parameterize on vector width. For example, the new definition of
> fadd is:
>
> binop("fadd", tfloat, commutative + associative, "src0 + src1")
>
> which mean that output_type, input_type[0], and input_type[1] are all
> nir_type_float. The same opcode is used for f32 and f64, and when we add an
> f16 type and a mediump/relaxed-precision "f24" type, not much will have to
> change.
>
> Now, if there are asserts we're missing to catch these sorts of things, then
> by all means go and add them. But having a nir_type_float around to mean
> "any width float will do" is one of the central points of the whole idea.
> Maybe we could rename it to "nir_type_float_all" or something?</span >
Ok, I see.
<span class="quote">> BTW, for the GPU hangs, some of them might be caused by this commit:
>
> <a href="http://cgit.freedesktop.org/~cwabbott0/mesa/commit/?h=i965-fp64">http://cgit.freedesktop.org/~cwabbott0/mesa/commit/?h=i965-fp64</a>-
> v3&id=1b38ed4e53da1a6a3e4ca1d659ce52f159e16037
>
> it removes an old hack from back when we used to guess the exec_size of an
> instruction which breaks fp64, but I wouldn't be surprised if removing it
> uncovers other hidden bugs. I didn't manage to test it (I think Jenkins was
> down when I tried last summer), but it would be nice to fix any regressions
> and get that merged ahead of the rest of the series.</span >
Yep, I noticed this on Friday, and removing it does indeed fix the remaining
hangs. I need to think more about what to do with that, if that really breaks
fp64 we'll have to try and fix the bugs that it is working around.</pre>
</div>
</p>
<hr>
<span>You are receiving this mail because:</span>
<ul>
<li>You are the QA Contact for the bug.</li>
</ul>
</body>
</html>