File: tex.rst

package info (click to toggle)
mesa 25.2.8-2
  • links: PTS, VCS
  • area: main
  • in suites: sid
  • size: 312,152 kB
  • sloc: ansic: 2,185,354; xml: 1,028,239; cpp: 512,236; python: 76,148; asm: 38,329; yacc: 12,198; lisp: 4,114; lex: 3,429; sh: 855; makefile: 237
file content (83 lines) | stat: -rw-r--r-- 2,941 bytes parent folder | download | duplicates (6)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
NIR Texture Instructions
========================

Even though texture instructions *could* be supported as intrinsics, the vast
number of combinations mean that doing so is practically impossible. Instead,
NIR has a dedicated texture instruction.  There are several texture operations:

.. c:autoenum:: nir_texop
   :file: src/compiler/nir/nir.h
   :members:

As with other instruction types, there is still an array of sources, except
that each source also has a *type* associated with it.  There are various
source types, each corresponding to a piece of information that the different
texture operations require.

.. c:autoenum:: nir_tex_src_type
   :members:

Of particular interest are the texture/sampler deref/index/handle source types.
First, note that textures and samplers are specified separately in NIR.  While
not required for OpenGL, this is required for Vulkan and OpenCL.  Some
OpenGL [ES] drivers have to deal with hardware that does not have separate
samplers and textures.  While not recommended, an OpenGL-only driver may assume
that the texture and sampler derefs will always point to the same resource, if
needed.  Note that this pretty well paints your compiler into a corner and
makes any future port to Vulkan or OpenCL harder, so such assumptions should
really only be made if targeting OpenGL ES 2.0 era hardware.

Also, like a lot of other resources, there are multiple ways to represent a
texture in NIR. It can be referenced by a variable dereference, an index, or a
bindless handle. When using an index or a bindless handle, the texture type
information is generally not available.  To handle this, various information
from the type is redundantly stored in the :c:struct:`nir_tex_instr` itself.

.. c:autostruct:: nir_tex_instr
   :members:

.. c:autostruct:: nir_tex_src
   :members:

Texture instruction helpers
---------------------------

There are a number of helper functions for working with NIR texture
instructions.  They are documented here in no particular order.

.. c:autofunction:: nir_tex_instr_create

.. c:autofunction:: nir_tex_instr_need_sampler

.. c:autofunction:: nir_tex_instr_result_size

.. c:autofunction:: nir_tex_instr_dest_size

.. c:autofunction:: nir_tex_instr_is_query

.. c:autofunction:: nir_tex_instr_has_implicit_derivative

.. c:autofunction:: nir_tex_instr_src_type

.. c:autofunction:: nir_tex_instr_src_size

.. c:autofunction:: nir_tex_instr_src_index

.. c:autofunction:: nir_tex_instr_add_src

.. c:autofunction:: nir_tex_instr_remove_src

Texture instruction lowering
----------------------------

Because most hardware only supports some subset of all possible GLSL/SPIR-V
texture operations, NIR provides a quite powerful lowering pass which is able
to implement more complex texture operations in terms of simpler ones.

.. c:autofunction:: nir_lower_tex

.. c:autostruct:: nir_lower_tex_options
   :members:

.. c:autoenum:: nir_lower_tex_packing
   :members: