All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
To: "Strasser, Kevin" <kevin.strasser@intel.com>
Cc: "intel-gfx@lists.freedesktop.org"
	<intel-gfx@lists.freedesktop.org>,
	"dri-devel@lists.freedesktop.org"
	<dri-devel@lists.freedesktop.org>
Subject: Re: [PATCH 0/3] Support 64 bpp half float formats
Date: Fri, 30 Nov 2018 16:15:53 +0200	[thread overview]
Message-ID: <20181130141553.GV9144@intel.com> (raw)
In-Reply-To: <51B6C3CD1F10FB47A5702881E0E230A793D1E56C@ORSMSX104.amr.corp.intel.com>

On Thu, Nov 29, 2018 at 09:39:52PM +0000, Strasser, Kevin wrote:
> Ville Syrjälä wrote:
> > On Wed, Nov 28, 2018 at 10:38:10PM -0800, Kevin Strasser wrote:
> >> This series defines new formats and adds a plane property to be used for
> >> floating point framebuffer content. Implementation is then added to i915.
> >>
> >> I have shared an IGT branch which adds test coverage for the new formats:
> >>   https://github.com/strassek/xorg-intel-gpu-tools/tree/fp16
> >
> > Looks about similar as what I had written. I wrote my half<->full
> > conversion thing from scratch which probably means it has more rounding
> > errors and whatnot. The speed of mine wasn't exactly stellar and looks
> > like your version probably has the same issue. So I was actually
> > thinking of using the sse<something> instructions meant for this
> > could provide a nice speedup. I guess we might want the pure c version
> > as a backup though. Hmm. Now I also seem to recall that I noticed
> > there being a compiler intrinsic even for single value half<->full
> > precision conversion. Did you look into using that (if I didn't imagine
> > it)?
> 
> You are thinking of vcvtps2ph and vcvtph2ps, I haven't yet had a chance to 
> give them a try, but I agree it seems like a good idea.
> 
> > BTW I just rebased my fp16 for pre-icl platforms:
> > git://github.com/vsyrjala/linux.git fp16_scanout_2
> >
> > Apart from the ivb/hsw w/a there isn't all that much unexpected
> > when it comes to fp16 on those platforms either.
> 
> I don't mean to step on your toes with this series, were you waiting for /  
> working on a real usecase before pushing that code?

I pretty much just did it so that I could test >10bpc gamma LUTs. But
I got sidetracked by other things so I didn't really get even that far.
Also another problem is that igt depends on cairo which didn't support
rendering at >10bpc, so I couldn't really test that stuff properly even
if I wanted to. Maarten has patches to wire up floats into cairo but I
think he just said that it still kinda uses 8bpc precision only :(

Anyways, the fact that you did icl and I did pre-icl is pretty good
division of labour. Sometimes things work out by accident :)

-- 
Ville Syrjälä
Intel
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

      reply	other threads:[~2018-11-30 14:15 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-11-29  6:38 [PATCH 0/3] Support 64 bpp half float formats Kevin Strasser
2018-11-29  6:38 ` [PATCH 1/3] drm/fourcc: Add " Kevin Strasser
2018-11-29 18:42   ` Ville Syrjälä
2018-11-29 21:38     ` Strasser, Kevin
2018-11-29  6:38 ` [PATCH 2/3] drm: Add optional PIXEL_NORMALIZE_RANGE property to drm_plane Kevin Strasser
2018-11-29 18:45   ` Ville Syrjälä
2018-11-29 21:38     ` Strasser, Kevin
2018-11-29  6:38 ` [PATCH 3/3] drm/i915: Implement half float formats and pixel normalize property Kevin Strasser
2018-11-29  9:18   ` Daniel Vetter
2018-11-29 17:52     ` Strasser, Kevin
2018-11-30  9:42       ` Daniel Vetter
2018-11-29 18:52   ` Ville Syrjälä
2018-11-29 21:39     ` Strasser, Kevin
2018-11-29  6:49 ` ✗ Fi.CI.BAT: failure for Support 64 bpp half float formats Patchwork
2018-11-29 19:26 ` [Intel-gfx] [PATCH 0/3] " Ville Syrjälä
2018-11-29 21:39   ` Strasser, Kevin
2018-11-30 14:15     ` Ville Syrjälä [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20181130141553.GV9144@intel.com \
    --to=ville.syrjala@linux.intel.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=kevin.strasser@intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.