summaryrefslogtreecommitdiff
path: root/src/render_program
AgeCommit message (Collapse)Author
2018-11-13sna: Added AYUV format support for textured and sprite video adapters.Stanislav Lisovskiy
v2: Renamed DRM_FORMAT_XYUV to DRM_FORMAT_XYUV8888. Added comment about AYUV byte ordering in Gstreamer. v3: Removed sna_composite_op flags related change to the separate patch. v4: Fixed review comments, done code refactoring v5: Fixed following review comments: - Fixed comment in shader code for ayuv kernel. - Fixed naming to VIDEO_AYUV_BT601/BT709 for ayuv kernels. - Removed duplicate gen9_kernel parameter, left from previous patches - Added colorspace handling for new AYUV kernel - Fixed naming of sna_copy_packed_data_ayuv to sna_copy_ayuv_data - Started using standard bswap_32 function for byte swapping in sna_copy_ayuv_data - Removed redundant code in sna_copy_ayuv_data so that it looks more neat - Fixed XVIMAGE_AYUV structure initialization to contain proper byte sequence for GST - Fixed bogus comment about subsampling for DRM_FORMAT_XYUV8888 - Fixed AYUV advertisement for all platforms - Removed unnecessary RGB888 declaration. v6: - Fixed surface format not to use alpha as supposed - Now doing byte swapping always during copy - Changed hack, required for GST to work to be at one place - Fixed invalid sampling values for XVIMAGE_AYUV - Fixed sprite format checking order and images_ayuv definition. v7: - Removed reverse_bytes bool parameter, now swapping bytes for XYUV unconditionally both for textured and sprite modes. v8: - Added gen9_images structure, in order to expose AYUV format to proper platforms. Signed-off-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
2018-05-31sna/video: Add XV_COLORSPACE attribute for the textured Xv adaptorVille Syrjälä
Allow the client to select between BT.601 and BT.709 via the XV_COLORSPACE port attribute with the textured Xv adaptor as well. Since the BT.601 coefficients are currently hardcoded in the yuv->rgb shader, let's just add a mostly duplicated shader with hardcoded BT.709 coefficients instead. Not the most elegant solution but avoids having to touch any state setup etc. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
2018-05-31Rename current yuv->rgb shader sources to exa_wm_yuv_rgb_bt601Ville Syrjälä
Our current yuv->rgb shaders follow the BT.601 conversion formula. Rename the shader sources to indicate that fact. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
2018-05-31Remove duplicate exa_wm_yuv_rgb.g5a shader sourceVille Syrjälä
exa_wm_yuv_rgb.g5a is identical to exa_wm_yuv_rgb.g4a. Just use a symlink intead of duplicating the whole file. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
2017-09-27sna/video: Add NV12 shader binariesVille Syrjälä
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
2017-09-27sna/video: Add NV12 shadersVille Syrjälä
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
2015-06-09Fix typos found with codespell v1.7Sedat Dilek
To get codespell v1.7 check [2]. [1] https://github.com/lucasdemarchi/codespell [2] https://github.com/lucasdemarchi/codespell/releases Signed-off-by: Sedat Dilek <sedat.dilek@gmail.com>
2015-04-16gen8: Fix the YUV->RGB shaderVille Syrjälä
Use the correct register (Yn_01) with first half of the Y samples instead of using the register (Yn_23) with the second half twice when computing the green channel. Also use the Yn_01 register name instead of Yn for the red channel as well, just for a bit of extra consistency. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=89807 Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Tested-by: Chris Wilson <chris@chris-wilson.co.uk>
2014-08-29gen8: Refresh video render programsChris Wilson
Reported-by: Timo Aaltonen <tjaalton@ubuntu.com> References: https://bugs.freedesktop.org/show_bug.cgi?id=83207 Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
2013-12-11sna/gen8: Initial backend for BroadwellChris Wilson
Should match the functionality of the earlier generations, but untuned. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
2013-02-18uxa/gen7: Don't use a message register to store vlDamien Lespiau
Turns out the "new" assembler that uses mesa's opcode emission hits the path that automatically transforms MRF registers into GRF ones in the exa_wm_src_projective shader. The diff with the new assembler is: $ intel-gen4disasm -g7 - - { 0x00600041, 0x208077be, 0x008d03c0, 0x008d0180 }, + { 0x00600041, 0x2e8077bd, 0x008d03c0, 0x008d0180 }, mul(8) m4<1>F g30<8,8,1>F g12<8,8,1>F { align1 }; mul(8) g116<1>F g30<8,8,1>F g12<8,8,1>F { align1 }; Of course, message registers are no more in gen7, so the shader is trying to do something shaddy (ahem!). Instead of using m4, let's make exa_wm_src_projective use g68 for v (aka vl) which makes sense since: 1/ vh is g69 2/ exa_wm_src_affine uses g68 for vl already This commit changes the generated assembly, here's the decoded diff: $ intel-gen4disasm -g7 - - { 0x00600041, 0x208077be, 0x008d03c0, 0x008d0180 }, + { 0x00600041, 0x288077bd, 0x008d03c0, 0x008d0180 }, mul(8) m4<1>F g30<8,8,1>F g12<8,8,1>F { align1 }; mul(8) g68<1>F g30<8,8,1>F g12<8,8,1>F { align1 }; Cc: Kenneth Graunke <kenneth@whitecape.org> Reported-by: Xiang, Haihao <haihao.xiang@intel.com> Signed-off-by: Damien Lespiau <damien.lespiau@intel.com> Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
2013-02-04build: Make generation of gen code depend on intel-gen4asmDamien Lespiau
This way, when a new intel-gen4asm is available (because one just hacked on it and has installed a new version for instance) the shaders will be recompiled. This helps catching regressions, testing the latest changes in the assembler haven't broken too many things. Signed-off-by: Damien Lespiau <damien.lespiau@intel.com> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
2013-02-04build: Use $(AM_V_GEN) to silence the assembly of gen programsDamien Lespiau
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
2012-10-07Use path for intel-gen4asm derived from pkg-configChris Wilson
As we use pkg-config to determine whether to use intel-gen4asm, we should also use it to locate the right version of intel-gen4asm to use. This allows the user to install the assembler in a non-standard path for cross-builds and similar. Reported-by: Josh Tripplet <josh@freedesktop.org> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=55646 Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
2011-11-24src/sna/gen5: Replace the precompiled shadersChris Wilson
Take advantage of a couple of new instructions introduced with Cantiga to reduce the instruction count inside the shaders and improve performance by around 10% in the fish-demo. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
2011-07-28render: New Ivybridge assembly programs for render acceleration.Kenneth Graunke
These are exactly the same as the ones for Sandybridge, but with message registers translated (hopefully) in the same way as Haihao's new programs (m1 == g65). Signed-off-by: Kenneth Graunke <kenneth@whitecape.org> Acked-by: Eric Anholt <eric@anholt.net> Acked-by: Chris Wilson <chris@chris-wilson.co.uk>
2011-06-24Xv: New shaders for Xv on IvybridgeXiang, Haihao
Redefine some M4 macros, also update the check for intel-gen4asm to support Ivybridge Signed-off-by: Xiang, Haihao <haihao.xiang@intel.com>
2011-06-24Xv: separate fragments from M4 macrosXiang, Haihao
It is to prepare for Xv on Ivybridge. The difference from Sandybridge is that all message payload must be in GRF registers instead of MRF registers on Ivybridge. We will only redefine some M4 macros for Ivybridge Signed-off-by: Xiang, Haihao <haihao.xiang@intel.com>
2010-11-02render: use headerless render target writeXiang, Haihao
It is weird that some rendercheck cases only work fine with headerless write. Need to update intel-gen4asm to support headerless write Signed-off-by: Xiang, Haihao <haihao.xiang@intel.com>
2010-11-02render: fragments for composite on SandybridgeXiang, Haihao
Signed-off-by: Xiang, Haihao <haihao.xiang@intel.com>
2010-11-02render: fix send instruction used in sampling fragmentsXiang, Haihao
To prepare for composite on Sandybridge Signed-off-by: Xiang, Haihao <haihao.xiang@intel.com>
2010-11-01Xv: fragments for xv on Sandybridge.Xiang, Haihao
Need to update intel-gen4asm to build these fragments Signed--off-by: Xiang, Haihao <haihao.xiang@intel.com>
2010-11-01Xv: Send instruction doesn't use implied move when sampling YUV surfaceXiang, Haihao
The two fragments will be reused for sampling YUV surface and send doesn't have implied move on Sandybridge Signed-off-by: Xiang, Haihao <haihao.xiang@intel.com>
2009-08-05Fix sampler indexes on i965 planar video.Eric Anholt
We only set up one sampler, because all of our sampling is the same. By using a non-zero index for the other two samplers, we'd dereference (likely) zeroed data, resulting in using NEAREST filtering. This was a regression in 40671132cb3732728703c6444f4577467fa9223f which incidentally switched from having 6 samplers to 1. Bug #22895, #19856
2009-07-06remove unused shader programRémi Cardona
This file is not even referenced by any Makefile.am Acked-by: Zhenyu Wang <zhenyuw@linux.intel.com>
2009-06-30Remove unused packed yuv sampler shader programsZhenyu Wang
Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
2009-06-30Add new compiled shader program for IGDNGZhenyu Wang
Also check intel-gen4asm tool here for new -g option, which is required to compile new programs. Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
2009-06-30Move shader programs under its own subdirectoryZhenyu Wang
Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
generated by cgit v1.2.3 (git 2.25.1) at 2024-11-26 17:54:00 +0000