In the current implementation the value for this parameter is 128 texture requests (each texture requests corresponds with a fragment quad).
Format
Integer
TwoLevelTextureCache
Description
When the parameter is set to TRUE the Texture Cache is implemented as two caches. The first cache, and smaller cache, holds uncompressed texture data and should have enough bandwidth to service all texels for a bilinear request for a fragment quad in a cycle (at least for 32-bit texture formats). The second, larger to hide latency and to profit from texture access locality, holds uncompressed texture data and the bandwidth should be enough to keep the level one cache filled.
When the parameter is set to FALSE the Texture Cache is implemented as a single cache. The cache would hold uncompressed texture data.
In the current implementation due to a large memory transaction size (64 bytes) when the parameter is set to FALSE the cache line size should be at least 256 bytes or memory bandwidth would be wasted for compressed textures (uncompressed size is x8 for DXT1, x4 for DXT3/DXT5).
In our current configuration files the parameter is set to TRUE.
Format
Boolean (TRUE/FALSE)
TextureCacheLineSize
Description
When TwoLevelTextureCache is set to TRUE this parameter defines the size of the first level (L0) cache line in bytes.
When TwoLevelTextureCache is set to FALSE this parameter defines the size of the Texture Cache line in bytes.
In both cases the cache line size defined is for uncompressed data. So take that into account depending on the actual size of the minimum request possible to the next memory level for possible loses of bandwidth due to the decompression ratio.
Cache size is computed as :
TextureCacheWays * TextureCacheLines * TextureCacheLineSize
In our current configuration files the line size is set to 64 bytes.
Format
Integer
TextureCacheWays
Description
When TwoLevelTextureCache is set to TRUE this parameter defines the number of ways (associativity) in the first level (L0) cache.
When TwoLevelTextureCache is set to FALSE this parameter defines the number of ways (associativity) in the Texture Cache.
Cache size is computed as :
TextureCacheWays * TextureCacheLines * TextureCacheLineSize
In our current configuration files this parameter is set to 8 ways.
Format
Integer
TextureCacheLines
Description
When TwoLevelTextureCache is set to TRUE this parameter defines the number of lines per way in the first level (L0) cache.
When TwoLevelTextureCache is set to FALSE this parameter defines the number of lines per way ( in the Texture Cache.
Cache size is computed as :
TextureCacheWays * TextureCacheLines * TextureCacheLineSize
In our current configuration files this parameter is set to 8 ways.
Format
Integer
TextureCachePortWidth
Description
Defines how many bytes are read from each 'port' in the first level (L0) Texture Cache or when the Texture Cache is implemented as a single cache. There are 4x4 ports (4 texel, 4 fragments) to service all the texels in a bilinear sample for a fragment quad in a single cycle without restrictions.
In our current configuration files this parameter is set to 4 bytes.
Format
Integer
TextureCacheRequestQueueSize
Description
Defines the size of the buffer (FIFO) that stores cache line requests to memory.
The buffer defined by this parameter is implemented in the FetchCache class and stores requests for texture misses (fills from memory and spills to memory if eviction is required, not the case for the Texture Cache).
This buffer limits the maximum number of out-standing misses for the Texture Cache. Given that the Texture Unit requires a large number of out-standing misses to completely hide memory latency a relatively large number of entries is required for good performance.
When the TwoLevelTextureCache parameter is set to TRUE The value of this parameter is used for both instances of the FetchClass: one for the first level cache (L0) and another for the second level cache (L1).
A propper performance evaluation of this parameter and the required number of out standing misses for the Texture Cache for a given memory configuration (latency) has not performed.
In our current configuration files the value of this parameter is set to 128 misses.
Format
Integer
TextureCacheInputQueue
Description
Defines the size of the buffer (FIFO) that holds Texture Cache requests for misses.
The buffer defined by this parameter is implemented in the TextureCache class. The value of this parameter limits the number of outstanding misses supported by the Texture Cache. The actual limit is the minimum of the value of this parameter and the value of the TextureCacheRequestQueueSize parameter.
When TwoLevelTextureCache is set to TRUE this defines the size of the buffer for the first level cache (L0).
The performance impact of this parameter and the actual number of outstanding misses required to completely hide the latency of a given memory configuration has not been propperly evaluated.
In our current configuration files the value of this parameter is 128 misses.
Format
Integer
TextureCacheMissesPerCycle
Description
Defines how many misses can be generated per cycle by the Texture Cache.
In a single cycle the Texture Cache supports up to 16 fetch operations (4 texels for a bilinear for 4 fragments). If the number of misses for those 16 fetch operations exceed the value defined for this parameter the Texture Cache logic will iterate over the same group of 16 fetch operations untill all the required missed lines are enqueued in the miss buffers of the Texture Cache.
The actual performance impact of this parameter has not been evaluated.
In our current configuration files the value of this parameter is 8 misses. Not sure if we use this value due to results from experiments or based on the analysis of actual hardware implementations.
Format
Integer
TextureCacheDecompressLatency
Description
Defines the latency in cycles of the texture decompression stage implemented in the Texture Cache.
In the current implementation the texture decompression stage isn't pipelined so only a single cache line can be decompressed at a time. Latencies greater than 1 reduce the throughput of the decompression stage and thus the actual bandwidth into the Texture Cache. This may be changed in future implementations.
In our current configuration files this parameter is set to 1 cycle. The reason is that the current implementation doesn't model a pipelined texture decompression stage and a latency higher than 1 would greatly reduce the bandwidth into the Texture Cache.
Format
Integer
TextureCacheLineSizeL1
Description
When TwoLevelTextureCache is set to TRUE this parameter defines the size of the second level (L1) cache line in bytes.
When TwoLevelTextureCache is set to FALSE this parameter is not used.
Lines in the second level cache may hold compressed texture data.
Second level (L1) cache size is computed as :
TextureCacheWaysL1 * TextureCacheLinesL1 * TextureCacheLineSizeL1.
In our current configuration files the line size is set to 64 bytes.
Format
Integer
TextureCacheWaysL1
When TwoLevelTextureCache is set to TRUE this parameter defines the number of ways (associativity) in the second level (L1) cache.
When TwoLevelTextureCache is set to FALSE this parameter is not used.
Second level (L1) Texture Cache size is computed as :
TextureCacheWaysL1 * TextureCacheLinesL1 * TextureCacheLineSizeL1
In our current configuration files this parameter is set to 8 ways.
Format
Integer
TextureCacheLinesL1
Description
When TwoLevelTextureCache is set to TRUE this parameter defines the number of lines per way in the second level (L1) cache.
When TwoLevelTextureCache is set to FALSE this parameter is not used.
Second level (L1) Texture Cache size is computed as :
TextureCacheWaysL1 * TextureCacheLinesL1 * TextureCacheLineSizeL1
In our current configuration files this parameter is set to 8 ways.
Format
Integer
TextureCacheInputQueueL1
Description
Defines the size of the buffer (FIFO) that holds Texture Cache requests for misses.
The buffer defined by this parameter is implemented in the TextureCache class. The value of this parameter limits the number of outstanding misses supported by the Texture Cache. The actual limit is the minimum of the value of this parameter and the value of the TextureCacheRequestQueueSize parameter.
When TwoLevelTextureCache is set to TRUE this defines the size of the buffer for the second level cache (L1).
When TwoLevelTextureCache is set to FALSE this parameter is not used.
In the current implementation the value of this parameter and TextureCacheInputQueue (first level cache) may limit each other. A propper evaluation of the current implementation is required.
The performance impact of this parameter and the actual number of outstanding misses required to completely hide the latency of a given memory configuration has not been propperly evaluated.
In our current configuration files the value of this parameter is 128 misses.
Format
Integer
ZSTENCILTEST section
ROPZ parameters
StampsPerCycle (ROPZ)
Description
Defines the number of fragment quads per cycle that the Z and Stencil Test unit (ROPZ) can receive from and return back to Fragment FIFO.
In the current implementation the Z and Stencil Test unit (ROPZ) internal throughput is limited to a single fragment quad per cycle and when multisampling antialiasing is enabled to a single sample per fragment read or written to the Z Cache. This may change in future implementations.
The value of this parameter should match the value defined for the StampsPerCycle (RASTERIZER section) divided by the value defined by the NumStampPipes parameter (GPU section).
In our current configuration files this parameter is set to 1 fragment quad.
Format
Integer
BytesPerPixel (ROPZ)
Description
In the original implementation this value represented the bytes per fragment for depth+stencil. In the current implementation this parameter is deprecated (the bit depth of the depth stencil buffer may be fixed or configurable through a GPU register) and not longer used.
This parameter will be eventually removed.
Format
Integer
Z Cache parameters
ZCacheWays
Description
Defines the number of ways (associativity) of the Z Cache.
The Z Cache size is computed as :
ZCacheWays * ZCacheLines * ZCacheStampsPerLine * 16
In the current implementation this parameter is set to 4 ways (Z Cache size of 16 KBs).
Format
Integer
ZCacheLines
Description
Defines the number of line per way of the Z Cache.
The Z Cache size is computed as :
ZCacheWays * ZCacheLines * ZCacheStampsPerLine * 16
In our current configuration files this parameter is set to 16 lines (Z Cache size of 16 KBs).
Format
Integer
ZCacheStampsPerLine
Description
Defines the size of the Z Cache lines.
In the current implementation the size is defined as number of fragment quads (2x2 fragments) for 32-bit (4 bytes) fragments. The actual cache line size in bytes can be obtained by multiplying the value assigned to this parameter by 16 bytes.
The Z Cache size is computed as :
ZCacheWays * ZCacheLines * ZCacheStampsPerLine * 16
In our current configuration files this parameter is set to 16 (256 bytes per cache line, total 16 KBs for the Z Cache).
Format
Integer
ZCachePortWidth
Description
Defines how many bytes can be read or write through the Z Cache ports. Defines the bandwidth between the Z Cache and the Z and Stencil Test unit.
As the Z and Stencil Test unit can process one fragment quad per cycle for 32-bit (4 bytes) per fragment depth+stencil the minimum bandwidth required with the Z cache for read or write operations is 16 bytes.
In our current implementation this parameter is set to 32 bytes. I think that with the current implementation the value should be 16. The current value would valid if the Z and Stencil Test unit could read or write two samples per cycle but that's not the case. Likely the implementation will change to fix this limitation.
Format
Integer
ZCacheExtraReadPort
Description
When this parameter is set to TRUE an extra read port is modeled in the Z Cache. This allows for a read operation from Z and Stencil Test unit in parallel with a read for a Z cache line eviction.
When the Z cache was first implemented it was detected that without the two read and two write ports the performance reduction due to contention from cache line evictions and fills was quite noticeable. This feature and parameter were added to prevent that performance reduction.
In our current configuration files this parameter is set to TRUE. Eventually a more realistic model should be implemented but some mechanism (banked cache) to reduce contention may be required.
Format
Boolean (TRUE/FALSE)
ZCacheExtraWritePort
Description
When this parameter is set to TRUE an extra write port is modeled in the Z Cache. This allows for a write operation from Z and Stencil Test unit in parallel with a write for a Z cache line fill.
When the Z cache was first implemented it was detected that without the two read and two write ports the performance reduction due to contention from cache line evictions and fills was quite noticeable. This feature and parameter were added to prevent that performance reduction.
In our current configuration files this parameter is set to TRUE. Eventually a more realistic model should be implemented but some mechanism (banked cache) to reduce contention may be required.
Format
Boolean (TRUE/FALSE)
ZCacheRequestQueueSize
Description
Defines the size of the buffer (FIFO) that stores misses while they are being serviced.
This buffer is implemented in the FetchCache class and each entry stores information for both the spill (eviction) and fill (miss service) associated with the miss.
This value assigned to this parameter limits the number of outstanding misses supported by the Z Cache. This number affects the memory latency hiding capability of the Z and Stencil Test stage.
It has been evaluated that a reduced number of outstanding misses reduces the performance of the Memory Controller.
In our current configuration files this parameter is set to 128 misses.
Format
Integer
ZCacheInputQueueSize
Description
Defines the size of the buffer (FIFO) that stores cache line fill operations while they are being serviced from memory.
This buffer is implemented in the ROPCache class and each entry stores information cache line fill operations associated with a cache miss.
This value assigned to this parameter limits the number of outstanding misses supported by the Z Cache. This number affects the memory latency hiding capability of the Z and Stencil Test stage.
It has been evaluated that a reduced number of outstanding misses reduces the performance of the Memory Controller.
In our current configuration files this parameter is set to 128 misses.
Format
Integer
ZCacheOutputQueueSize
Defines the size of the buffer (FIFO) that stores cache line spill (eviction) operations while they are being serviced to memory.
This buffer is implemented in the ROPCache class and each entry stores information cache line spill operations associated with a cache miss.
This value assigned to this parameter limits the number of outstanding misses supported by the Z Cache. This number affects the memory latency hiding capability of the Z and Stencil Test stage.
It has been evaluated that a reduced number of outstanding misses reduces the performance of the Memory Controller.
In our current configuration files this parameter is set to 128 misses.
Format
Integer
BlockStateMemorySize (ROPZ)
Description
Defines for how many framebuffer blocks (1 block = 1 cache line) the Z cache can hold the compression and clear state.
For framebuffer compression and fast clear support the Z Cache stores a per cache line (framebuffer block) value of a few bits (for example, 2 to 4 bits) that defines the current state of corresponding cache line (framebuffer block) as stored in memory: cleared, compressed with different compression ratios or algorithms or uncompressed.
In the current implementation the total size of the block state memory through all the Z Caches limits the maximum size of the depth+stencil buffer with fast clear, compression and Hierarchical Z buffer support.
Take into account that when multisampling antialising is enabled the maximum size of the framebuffer in terms of pixel resolution decreases as the size in bytes of a framebuffer block (cache line) doesn't change.
In the current implementation this parameter is set to 262144 blocks.
Format
Integer
BlocksClearedPerCycle (ROPZ)
Description
Defines the number of blocks for which the state can be cleared per cycle in the block state memory of the Z Cache. Defines how fast the fast clear operation is actually performed.
As a block state requires only 2 to 4 bits clearing (actually writing) a relatively large number of values per cycle may be possible.
Fast clear operations are already fast due to using an internal state memory and clearing blocks, not pixels, so for performance the number of blocks cleared per cycle doesn't need to be that large.
In our current configuration files this parameter is set to 1024 blocks.
Format
Integer
DisableCompression (ROPZ)
Description
When this parameter is set to TRUE compression of cache lines (1 cache line = 1 depth+stencil buffer block = 1 HZ buffer block) when are evicted to memory is disabled.
This parameter has a considerable performance effect due to the increase in bandwidth required with memory and because when Z Cache compression is disabled the Hierarchical Z test has to be disabled (DisableHZ parameter in RASTERIZER section).
In our current configuration files this parameter is set to FALSE.
Format
Boolean (TRUE/FALSE)
CompressionAlgorithm (ROPZ)
Description
Defines the compression algorithm that is used to compress Z Cache lines evicted to memory.
Currently implemented compression algorithms are:
- 0 : HiLo algorithm (original). The implemented algorithm is actually suitable only for depth compression and the presence of varying stencil values will greatly reduce performance. The algorithm is based on an ATI patent for depth compression. Two reference depth values are stored per block and two extra depth values are derived from the reference depth values. These four values are used as the high (MSB) bits of the block depth values. The block depth values are compressed as indices to one of these four depth values and an offset (lower bits, LSB). Only two compression ratios are supported: 2x, 4x.
- 1 : An enhanced implementation of the HiLo algorithm that supports up to 3 compression ratios and rearranging the MSB and LSB relative to the different fragment/sample fields (stencil/depth or R/G/B/A). Iplemented by Christian, look at code and his Master Thesis for details.
- 2 : MSAA compression algorithm. Implemented by Christian, look at code and his Master Thesis for details.
For the Z Cache only a specialized version of the HiLo algorithm for depth and 3 compression ratios is currently implemented. The compression algorithm code is 0. Therefore this parameter can only be set to 0.
In our current configuration files this parameter is set to 0.
Format
Integer
CompressionUnitLatency (ROPZ)
Description
Defines the number of cycles required to compress a Z Cache line that is being evicted to memory.
In the current implementation the modeled compression stage is not pipelined. The value assigned to this parameter may reduce the actual bandwidth from the Z Cache to the Memory Controller.
In our current configuration files this parameter is set to 8 cycles. Note that given a cache line size of 256 bytes and a maximum bandwidth to the Memory Controller of 64 bytes per cycle the actual bandwidth is reduced to 32 bytes per cycle with this value. However the Z Cache can compress a cache line and decompress another cache line in parallel so the maximum bandwidth with the Memory Controller can actually be maxed.
Format
Integer
DecompressionUnitLatency (ROPZ)
Description
Defines the number of cycles required to decompress a Z Cache line that is being evicted to memory.
In the current implementation the modeled decompression stage is not pipelined. The value assigned to this parameter may reduce the actual bandwidth from the Z Cache to the Memory Controller.
In our current configuration files this parameter is set to 8 cycles. Note that given a cache line size of 256 bytes and a maximum bandwidth to the Memory Controller of 64 bytes per cycle the actual bandwidth is reduced to 32 bytes per cycle with this value. However the Z Cache can compress a cache line and decompress another cache line in parallel so the maximum bandwidth with the Memory Controller can actually be maxed.
Format
Integer
InputQueueSize (ROPZ)
Description
Defines the size of the buffer (FIFO) that stores fragment quads received from the Fragment FIFO (Shader Work Distributor) stage.
From this queue the fragment quads are issued to the Z Cache fetch/allocate stage.
In our current configuration files this parameter is set to 8 fragment quads.
Format
Integer
FetchQueueSize (ROPZ)
Description
Defines the size of the buffer (FIFO) that stores fragment quads that already peformed the Z cache fetch/allocate operation and are waiting to read data from the cache.
This buffer is the main limit to the memory latency capability of the Z and Stencil Test stage so it should be relatively large.
In our current implementation this parameter is set to 256 fragment quads.
Format
Integer
ReadQueueSize (ROPZ)
Description
Defines the size of the buffer (FIFO) that stores fragment quads that already read data from the Z cache and are waiting to performe the Z and Stencil test.
In our current configuration files this parameter is set to 16 fragment quads.
Format
Integer
OpQueueSize (ROPZ)
Description
Defines the size of the buffer (FIFO) that holds fragment quads that were already tested and are waiting to be write the results of the test back to the Z Cache.
In our current configuration files this parameter is set to 4 fragment quads.
Format
Integer
WriteQueueSize
Description (ROPZ)
Defines the size of the buffer (FIFO) that stores fully processed fragment quads that are waiting to be returned to the Fragment FIFO stage.
In our current configuration files this parameter is set to 8 fragment quads.
Format
Integer
ZALUTestRate
Description
Defines the number of iterations (cycles) through the Z and Stencil Test ALUs required to process a fragment quad.
In the current implementation this parameter is used to reduce the throughput of the Z and Stencil Test stage to less than one fragment quad per cycle.
In our current configuration files this parameter is set to 1 cycle.
Format
Integer
ZALULatency
Description
Defines the latency in cycles of the Z and Stencil Test ALU that implements the tests.
In our current configuration files this parameter is set to 2 cycles.
Format
Integer
COLORWRITE section
ROPC parameters
StampsPerCycle (ROPC)
Defines the number of fragment quads per cycle that the Color Write unit (ROPC) can receive from Fragment FIFO.
In the current implementation the Color Write unit (ROPC) internal throughput is limited to a single fragment quad per cycle and when multisampling antialiasing is enabled to a single sample per fragment read or written to the Color Cache. This may change in future implementations.
The value of this parameter should match the value defined for the StampsPerCycle (RASTERIZER section) divided by the value defined by the NumStampPipes parameter (GPU section).
In our current configuration files this parameter is set to 1 fragment quad.
Format
Integer
BytesPerPixel (ROPC)
Description
In the original implementation this value represented the bytes per fragment for color. In the current implementation this parameter is deprecated (the bit depth of the color buffer may be fixed or configurable through a GPU register) and not longer used.
This parameter will be eventually removed.
Format
Integer
Color Cache parameters
ColorCacheWays
Description
Defines the number of ways (associativity) of the Color Cache.
The Color Cache size is computed as :
ColorCacheWays * ColorCacheLines * ColorCacheStampsPerLine * 16
In the current implementation this parameter is set to 4 ways (Color Cache size of 16 KBs).
Format
Integer
ColorCacheLines
Description
Defines the number of line per way of the Color Cache.
The Color Cache size is computed as :
ColorCacheWays * ColorCacheLines * ColorCacheStampsPerLine * 16
In our current configuration files this parameter is set to 16 lines (Color Cache size of 16 KBs).
Format
Integer
ColorCacheStampsPerLine
Description
Defines the size of the Color Cache lines.
In the current implementation the size is defined as number of fragment quads (2x2 fragments) for 32-bit (4 bytes) fragments. The actual cache line size in bytes can be obtained by multiplying the value assigned to this parameter by 16 bytes.
The Z Cache size is computed as :
ColorCacheWays * ColorCacheLines * ColorCacheStampsPerLine * 16
In our current configuration files this parameter is set to 16 (256 bytes per cache line, total 16 KBs for the Color Cache).
Format
Integer
ColorCachePortWidth
Description
Defines how many bytes can be read or write through the Color Cache ports. Defines the bandwidth between the Color Cache and the Color Write unit.
As the Color Write unit can process one fragment quad per cycle for 32-bit (4 bytes) per fragment color the minimum bandwidth required with the Color cache for read or write operations is 16 bytes.
In our current implementation this parameter is set to 32 bytes. I think that with the current implementation the value should be 16. The current value would valid if the Color Write unit could read or write two samples per cycle but that's not the case. Likely the implementation will change to fix this limitation.
Format
Integer
ColorCacheExtraReadPort
Description
When this parameter is set to TRUE an extra read port is modeled in the Color Cache. This allows for a read operation from Color Write unit in parallel with a read for a Color cache line eviction.
When the Color cache was first implemented it was detected that without the two read and two write ports the performance reduction due to contention from cache line evictions and fills was quite noticeable. This feature and parameter were added to prevent that performance reduction.
In our current configuration files this parameter is set to TRUE. Eventually a more realistic model should be implemented but some mechanism (banked cache) to reduce contention may be required.
Format
Boolean (TRUE/FALSE)
ColorCacheExtraWritePort
Description
When this parameter is set to TRUE an extra write port is modeled in the Color Cache. This allows for a write operation from Color Write unit in parallel with a write for a Color cache line fill.
When the Color cache was first implemented it was detected that without the two read and two write ports the performance reduction due to contention from cache line evictions and fills was quite noticeable. This feature and parameter were added to prevent that performance reduction.
In our current configuration files this parameter is set to TRUE. Eventually a more realistic model should be implemented but some mechanism (banked cache) to reduce contention may be required.
Format
Boolean (TRUE/FALSE)
ColorCacheRequestQueueSize
Description
Defines the size of the buffer (FIFO) that stores misses while they are being serviced.
This buffer is implemented in the FetchCache class and each entry stores information for both the spill (eviction) and fill (miss service) associated with the miss.
This value assigned to this parameter limits the number of outstanding misses supported by the Color Cache. This number affects the memory latency hiding capability of the Color Write stage.
It has been evaluated that a reduced number of outstanding misses reduces the performance of the Memory Controller.
In our current configuration files this parameter is set to 128 misses.
Format
Integer
ColorCacheInputQueueSize
Description
Defines the size of the buffer (FIFO) that stores cache line fill operations while they are being serviced from memory.
This buffer is implemented in the ROPCache class and each entry stores information cache line fill operations associated with a cache miss.
This value assigned to this parameter limits the number of outstanding misses supported by the Color Cache. This number affects the memory latency hiding capability of the Color Write stage.
It has been evaluated that a reduced number of outstanding misses reduces the performance of the Memory Controller.
In our current configuration files this parameter is set to 128 misses.
Format
Integer
ColorCacheOutputQueueSize
Description
Defines the size of the buffer (FIFO) that stores cache line spill (eviction) operations while they are being serviced to memory.
This buffer is implemented in the ROPCache class and each entry stores information cache line spill operations associated with a cache miss.
This value assigned to this parameter limits the number of outstanding misses supported by the Color Cache. This number affects the memory latency hiding capability of the Color Write stage.
It has been evaluated that a reduced number of outstanding misses reduces the performance of the Memory Controller.
In our current configuration files this parameter is set to 128 misses.
Format
Integer
BlockStateMemorySize (ROPC)
Description
Defines for how many framebuffer blocks (1 block = 1 cache line) the Color cache can hold the compression and clear state.
For framebuffer compression and fast clear support the Color Cache stores a per cache line (framebuffer block) value of a few bits (for example, 2 to 4 bits) that defines the current state of corresponding cache line (framebuffer block) as stored in memory: cleared, compressed with different compression ratios or algorithms or uncompressed.
In the current implementation the total size of the block state memory through all the Color Caches limits the maximum size of the color buffer with fast clear and compression support.
Take into account that when multisampling antialising is enabled the maximum size of the framebuffer in terms of pixel resolution decreases as the size in bytes of a framebuffer block (cache line) doesn't change.
In the current implementation this parameter is set to 262144 blocks.
Format
Integer
BlocksClearedPerCycle (ROPC)
Description
Defines the number of blocks for which the state can be cleared per cycle in the block state memory of the Color Cache. Defines how fast the fast clear operation is actually performed.
As a block state requires only 2 to 4 bits clearing (actually writing) a relatively large number of values per cycle may be possible.
Fast clear operations are already fast due to using an internal state memory and clearing blocks, not pixels, so for performance the number of blocks cleared per cycle doesn't need to be that large.
In our current configuration files this parameter is set to 1024 blocks.
Format
Integer
DisableCompression (ROPC)
Description
When this parameter is set to TRUE compression of cache lines (1 cache line = 1 color buffer block) when are evicted to memory is disabled.
This parameter has a considerable performance effect due to the increase in bandwidth required with memory.
In our current configuration files this parameter is set to FALSE.
Format
Integer
CompressionAlgorithm (ROPC)
Description
Defines the compression algorithm that is used to compress Color Cache lines evicted to memory.
Currently implemented compression algorithms are:
* 0 : HiLo algorithm (original). The implemented algorithm is actually suitable only for depth compression and the presence of varying stencil values will greatly reduce performance. The algorithm is based on an ATI patent for depth compression. Two reference depth values are stored per block and two extra depth values are derived from the reference depth values. These four values are used as the high (MSB) bits of the block depth values. The block depth values are compressed as indices to one of these four depth values and an offset (lower bits, LSB). Only two compression ratios are supported: 2x, 4x. * 1 : An enhanced implementation of the HiLo algorithm that supports up to 3 compression ratios and rearranging the MSB and LSB relative to the different fragment/sample fields (stencil/depth or R/G/B/A). Implemented by Christian, look at code and his Master Thesis for details. * 2 : MSAA compression algorithm. Implemented by Christian, look at code and his Master Thesis for details.
In our current configuration files this parameter is set to 0.
Format
Integer
CompressionUnitLatency (ROPC)
Description
Defines the number of cycles required to compress a Color Cache line that is being evicted to memory.
In the current implementation the modeled compression stage is not pipelined. The value assigned to this parameter may reduce the actual bandwidth from the Color Cache to the Memory Controller.
In our current configuration files this parameter is set to 8 cycles. Note that given a cache line size of 256 bytes and a maximum bandwidth to the Memory Controller of 64 bytes per cycle the actual bandwidth is reduced to 32 bytes per cycle with this value. However the Color Cache can compress a cache line and decompress another cache line in parallel so the maximum bandwidth with the Memory Controller can actually be maxed.
Format
Integer
DecompressionUnitLatency
Description (ROPC)
Defines the number of cycles required to decompress a Color Cache line that is being evicted to memory.
In the current implementation the modeled decompression stage is not pipelined. The value assigned to this parameter may reduce the actual bandwidth from the Color Cache to the Memory Controller.
In our current configuration files this parameter is set to 8 cycles. Note that given a cache line size of 256 bytes and a maximum bandwidth to the Memory Controller of 64 bytes per cycle the actual bandwidth is reduced to 32 bytes per cycle with this value. However the Color Cache can compress a cache line and decompress another cache line in parallel so the maximum bandwidth with the Memory Controller can actually be maxed.
Format
Integer
InputQueueSize (ROPC)
Description
Defines the size of the buffer (FIFO) that stores fragment quads received from the Fragment FIFO (Shader Work Distributor) stage.
From this queue the fragment quads are issued to the Color Cache fetch/allocate stage.
In our current configuration files this parameter is set to 8 fragment quads.
Format
Integer
FetchQueueSize (ROPC)
Description
Defines the size of the buffer (FIFO) that stores fragment quads that already peformed the Color cache fetch/allocate operation and are waiting to read data from the cache.
This buffer is the main limit to the memory latency capability of the Color Write stage so it should be relatively large.
In our current implementation this parameter is set to 256 fragment quads.
Format
Integer
ReadQueueSize (ROPC)
Description
Defines the size of the buffer (FIFO) that stores fragment quads that already read data from the Color cache and are waiting to performe the color/blend operation.
In our current configuration files this parameter is set to 16 fragment quads.
Format
Integer
OpQueueSize (ROPC)
Description
Defines the size of the buffer (FIFO) that holds fragment quads that were already operated/blended and are waiting to be write the results of the operation back to the Color Cache.
In our current configuration files this parameter is set to 4 fragment quads.
Format
Integer
WriteQueueSize (ROPC)
Description
Defines the size of the buffer (FIFO) that stores fully processed fragment quads that are waiting to be eliminated (end of the fragment pipelined) or returned to the Fragment FIFO stage.
In our current configuration files this parameter is set to 8 fragment quads.
Format
Integer
BlendALUTestRate
Description
Defines the number of iterations (cycles) through the Color Blend ALUs required to process a fragment quad.
In the current implementation this parameter is used to reduce the throughput of the Color Write stage to less than one fragment quad per cycle.
In our current configuration files this parameter is set to 1 cycle.
Format
Integer
BlendALULatency
Description
Defines the latency in cycles of the Color Blend ALU that implements the color and blend operations.
In our current configuration files this parameter is set to 2 cycles.
Format
Integer
DAC section
BytesPerPixel (DAC)
Description
In the original implementation this parameter defined the bits (actually bytes) per fragment in the color buffer. The current implementation defines the bit depth of the color buffer format using a GPU register so this parameter has been deprecated and is no longer used.
This parameter will eventually removed.
Format
Integer
BlockSize
Description
Defines the size of framebuffer block in bytes. A framebuffer block corresponds with a Z Cache and Color Cache line.
In the current implementation the value of this parameter should match the cache line size for the Z Cache and Color Cache (or at least for the Color Cache). In future implementations the actual cache line size will be directly passed to the DAC and this parameter will be removed.
In our current configuration files this parameter is set to 256 bytes (matching Z Cache and Color Cache line sizes).
Format
Integer
BlockUpdateLatency
Description
Defines the latency in cycles for the block state memory updates received from the Color Cache.
In the current implementation the value of this parameter is the latency assigned to the signal between the Color Write units and the DAC that is used to pass the updates of the block state memory when a frame is finished.
We are not currently modeling a real DAC and the DAC unit is only used to dump the frames to a file for verification so realistic performance is not a current objective. In any case the block state memory should be accessable (through copies or direct access) to the DAC in a real implementation.
In our current configuration files this parameter is set to 1.
Format
Integer
BlocksUpdatedPerCycle
Description
Defines how many block state values can be received/stored per cycle from the Color Write units.
In the current implementation this parameter is set to 1024 blocks. Note that at 2 or 4 bits per block state value that's 256 or 512 bytes per cycle.
Format
Integer
BlockRequestQueueSize
Description
Defines the size of the buffer (FIFO) that stores information for framebuffer blocks that are being requested to memory and decompressed.
In our current configuration files this parameter is set to 32 blocks.
Format
Integer
DecompressionUnitLatency
Description
Defines the number of cycles required to decompress a framebuffer block.
The decompression stage in the DAC is not modeled as a pipelined unit so a value higher than 1 reduces the throughput of this stage and the effective bandwidth at which data for framebuffer blocks is read.
In our current configuration files this parameter is set to 1 cycle.
Format
Integer
RefreshRate
Description
Defines the screen refresh rate in cycles. Defines the frequency at which the DAC unit reads, decompresses and resolved the color buffer and sends the data to a display device (in the actual implementation a file in PPM format).
Only if SynchedRefresh is set to FALSE will the the value of this parameter be used to trigger the screen refresh operation in the DAC unit.
The current implementation of the DAC unit isn't used to correctly model a real DAC or the real costs of the screen refresh operation in memory bandwidth and strict timing requirements (refresh frequency, VBlank, HBlank, etc). For this reason the normal refresh mode, trigger the screen refresh operation based on a given frequency, is not really used in our current simulations and the feature has not been fully tested nor used for a long time.
This parameter was defined before the GPUClock parameter (GPU section) was implemented when there was no concept of 'real' time (defined as a base frequency) in the simulator. For this reason the refresh rate is defined in cycles. A likely change if we decide to model a real DAC will be to modify this parameter to define the actual refresh frequency in HZ rather than in cycles.
In our current configuration files this parameter is set to 5000000 cycles.
Format
Integer
SynchedRefresh
Description
When this parameter is set to TRUE the DAC will 'refresh the screen', actually dump the current color buffer into a file (in PPM format), is synchronized with the frame end (framebuffer swap command).
When this parameter is set to FALSE the DAC will 'refresh the screen' at the given rate defined by the RefreshRate parameter. This refresh mode would be the correct as implemented by real DAC units to send the framebuffer data to a screen or monitor.
The main purpose of this parameter is to be used to dump the framebuffer content after rendering has finished for debugging and validation purpose.
In the current implementation the DAC unit purpose isn't to accurately simulate the screen refresh and associated memory bandwidth and strict timing requirements. The normal refresh mode for this reason is only partially tested and has not been used for a long time.
In our current configuration files this parameter is set to TRUE.
Format
Boolean (TRUE/FALSE)
RefreshFrame
Description
When this parameter is set to TRUE 'screen refresh' is enabled in the DAC.
In the current implementation 'screen refresh' is implemented with the DAC unit reading, decompressing and resolving (when MSAA is enabled) the framebuffer to the final on screen image as fast as possible and dumping the contents to a file (in PPM format). The main use is to validate the simulation by checking the resulting image.
In the current implementation the purpose of the DAC unit isn't to implement the correct screen refresh operation with the associated memory bandwidth and strict timing requirements.
In our current configuration files this parameter is set to TRUE.
Format
Boolean (TRUE/FALSE)
SaveBlitSourceData
Description
When this parameter is set to TRUE the source data for all blits operations (using the Blitter unit) is dumped into a file (in PPM format).
The purpose of this feature is/was to help in the debug of the Blitter. It can also be used to log the usage of the Blitter operation (copy to texture in OpenGL).
In our current configuration this parameter is set to FALSE.
Format
Boolean (TRUE/FALSE)


This is a tool to remind you to stand for some time while you are at work.
Enable Notifications
Stand for
minutes
at the
start
middle
end
of every hour


Categories
Development
Courses
Bootcamps
Design
Courses
Bootcamps
Data Science
Courses
Bootcamps
Digital Marketing
Courses
Bootcamps
Finance
Courses
Bootcamps
10
Log in
Sign up
Sign Up and Enroll !!
Register
Already have an account ?
Sign In


Online Organizer
Next Event Remainder : Currently no events available
Next Event Remainder : {{nextEventRemainder}}
Add Event
Event Name :
Date :
Start Time :
Submit
Edit
Events on :
{{startDate | date:shortDate}}
{{event.eTime}} | {{event.eName}}


| Class and Description |
|---|
| Covert
Any protocol that is secure in the presence of covert adversaries should implement this interface.
|
| Malicious
Any protocol that is secure in the presence of malicious adversaries should implement this interface.
|
| OneSidedSimulation |
| ProtocolSecLevel
This interface is the root interface of the security level hierarchy for (secure computation) protocols.
|
| SecurityLevel
Many cryptographic primitives and schemes have different security levels.
|
| SemiHonest
Any protocol that is secure in the presence of semi-honest adversaries should implement this interface.
|
| StandAlone
Any protocol that is proven secure in the stand-alone model (where secure protocols are run sequentially and not concurrently) should implement this interface.
|
| Class and Description |
|---|
| CommitSecLevel |
| PerfectlyBindingCmt
Any commitment scheme that is perfectly binding should implement this interface.
|
| SecureCommit |
| SecurityLevel
Many cryptographic primitives and schemes have different security levels.
|
| Class and Description |
|---|
| CommitSecLevel |
| SecureCommit |
| SecurityLevel
Many cryptographic primitives and schemes have different security levels.
|
| Class and Description |
|---|
| CommitSecLevel |
| EquivocalCmt |
| SecureCommit |
| SecurityLevel
Many cryptographic primitives and schemes have different security levels.
|
| Class and Description |
|---|
| CommitSecLevel |
| PerfectlyHidingCmt
Any commitment scheme that is perfectly hiding should implement this interface.
|
| SecureCommit |
| SecurityLevel
Many cryptographic primitives and schemes have different security levels.
|
| StatisticallyHidingCmt |
| Class and Description |
|---|
| CommitSecLevel |
| PerfectlyHidingCmt
Any commitment scheme that is perfectly hiding should implement this interface.
|
| SecureCommit |
| SecurityLevel
Many cryptographic primitives and schemes have different security levels.
|
| StatisticallyHidingCmt |
| Class and Description |
|---|
| CommitSecLevel |
| PerfectlyHidingCmt
Any commitment scheme that is perfectly hiding should implement this interface.
|
| SecureCommit |
| SecurityLevel
Many cryptographic primitives and schemes have different security levels.
|
| StatisticallyHidingCmt |
| Class and Description |
|---|
| CommitSecLevel |
| SecureCommit |
| SecurityLevel
Many cryptographic primitives and schemes have different security levels.
|
| Class and Description |
|---|
| Covert
Any protocol that is secure in the presence of covert adversaries should implement this interface.
|
| Malicious
Any protocol that is secure in the presence of malicious adversaries should implement this interface.
|
| OneSidedSimulation |
| ProtocolSecLevel
This interface is the root interface of the security level hierarchy for (secure computation) protocols.
|
| SecurityLevel
Many cryptographic primitives and schemes have different security levels.
|
| SemiHonest
Any protocol that is secure in the presence of semi-honest adversaries should implement this interface.
|
| StandAlone
Any protocol that is proven secure in the stand-alone model (where secure protocols are run sequentially and not concurrently) should implement this interface.
|
| Class and Description |
|---|
| Covert
Any protocol that is secure in the presence of covert adversaries should implement this interface.
|
| Malicious
Any protocol that is secure in the presence of malicious adversaries should implement this interface.
|
| OneSidedSimulation |
| ProtocolSecLevel
This interface is the root interface of the security level hierarchy for (secure computation) protocols.
|
| SecurityLevel
Many cryptographic primitives and schemes have different security levels.
|
| SemiHonest
Any protocol that is secure in the presence of semi-honest adversaries should implement this interface.
|
| StandAlone
Any protocol that is proven secure in the stand-alone model (where secure protocols are run sequentially and not concurrently) should implement this interface.
|
| Class and Description |
|---|
| OneSidedSimulation |
| ProtocolSecLevel
This interface is the root interface of the security level hierarchy for (secure computation) protocols.
|
| SecurityLevel
Many cryptographic primitives and schemes have different security levels.
|
| Class and Description |
|---|
| Covert
Any protocol that is secure in the presence of covert adversaries should implement this interface.
|
| Malicious
Any protocol that is secure in the presence of malicious adversaries should implement this interface.
|
| OneSidedSimulation |
| ProtocolSecLevel
This interface is the root interface of the security level hierarchy for (secure computation) protocols.
|
| SecurityLevel
Many cryptographic primitives and schemes have different security levels.
|
| SemiHonest
Any protocol that is secure in the presence of semi-honest adversaries should implement this interface.
|
| Class and Description |
|---|
| ProtocolSecLevel
This interface is the root interface of the security level hierarchy for (secure computation) protocols.
|
| SecurityLevel
Many cryptographic primitives and schemes have different security levels.
|
| SemiHonest
Any protocol that is secure in the presence of semi-honest adversaries should implement this interface.
|
| Class and Description |
|---|
| PrivacyOnly |
| ProtocolSecLevel
This interface is the root interface of the security level hierarchy for (secure computation) protocols.
|
| SecurityLevel
Many cryptographic primitives and schemes have different security levels.
|
| Class and Description |
|---|
| ProtocolSecLevel
This interface is the root interface of the security level hierarchy for (secure computation) protocols.
|
| SecurityLevel
Many cryptographic primitives and schemes have different security levels.
|
| SemiHonest
Any protocol that is secure in the presence of semi-honest adversaries should implement this interface.
|
| Class and Description |
|---|
| Covert
Any protocol that is secure in the presence of covert adversaries should implement this interface.
|
| Malicious
Any protocol that is secure in the presence of malicious adversaries should implement this interface.
|
| OneSidedSimulation |
| ProtocolSecLevel
This interface is the root interface of the security level hierarchy for (secure computation) protocols.
|
| SecurityLevel
Many cryptographic primitives and schemes have different security levels.
|
| SemiHonest
Any protocol that is secure in the presence of semi-honest adversaries should implement this interface.
|
| StandAlone
Any protocol that is proven secure in the stand-alone model (where secure protocols are run sequentially and not concurrently) should implement this interface.
|
| UC
Any protocol that is universally composable (aka.
|
| Class and Description |
|---|
| MacSignSecLevel
This hierarchy specifies the security level of a message authentication code (MAC) or digital signature scheme.
|
| OneTime
Any MAC or signature scheme that is secure for one-time use only should implement this interface.
|
| SecurityLevel
Many cryptographic primitives and schemes have different security levels.
|
| UnlimitedTimes
Any MAC or signature scheme that is secure for an unlimited number of uses should implement this interface.
|
| Class and Description |
|---|
| Cca1
An encryption scheme that is secure in the presence of preprocessing chosen-ciphertext attacks
(meaning that the decryption oracle is available only before the challenge ciphertext is provided) should implement this interface.
|
| Cca2
An encryption scheme that is secure in the presence of (full) chosen-ciphertext attacks should implement this interface.
|
| Cpa
An encryption scheme that is secure in the presence of chosen-plaintext attacks should implement this interface.
|
| Eav
An encryption scheme that is only secure for eavesdropping adversaries (like a stream cipher) should implement this interface.
|
| EncSecLevel
This hierarchy specifies the security level of encryption schemes; it does not differentiate between symmetric and asymmetric encryption.
|
| Indistinguishable
This interface should be used when the security level of the encryption scheme is according to the regular indistinguishability game that defines privacy.
|
| NonMalleable
This interface should be used for encryption schemes that achieve non-malleability, meaning that it is infeasible for an adversary to generate a related ciphertext.
|
| SecurityLevel
Many cryptographic primitives and schemes have different security levels.
|
| Class and Description |
|---|
| Cca1
An encryption scheme that is secure in the presence of preprocessing chosen-ciphertext attacks
(meaning that the decryption oracle is available only before the challenge ciphertext is provided) should implement this interface.
|
| Cca2
An encryption scheme that is secure in the presence of (full) chosen-ciphertext attacks should implement this interface.
|
| Cpa
An encryption scheme that is secure in the presence of chosen-plaintext attacks should implement this interface.
|
| Eav
An encryption scheme that is only secure for eavesdropping adversaries (like a stream cipher) should implement this interface.
|
| EncSecLevel
This hierarchy specifies the security level of encryption schemes; it does not differentiate between symmetric and asymmetric encryption.
|
| Indistinguishable
This interface should be used when the security level of the encryption scheme is according to the regular indistinguishability game that defines privacy.
|
| NonMalleable
This interface should be used for encryption schemes that achieve non-malleability, meaning that it is infeasible for an adversary to generate a related ciphertext.
|
| SecurityLevel
Many cryptographic primitives and schemes have different security levels.
|
| Class and Description |
|---|
| MacSignSecLevel
This hierarchy specifies the security level of a message authentication code (MAC) or digital signature scheme.
|
| OneTime
Any MAC or signature scheme that is secure for one-time use only should implement this interface.
|
| SecurityLevel
Many cryptographic primitives and schemes have different security levels.
|
| UnlimitedTimes
Any MAC or signature scheme that is secure for an unlimited number of uses should implement this interface.
|
| Class and Description |
|---|
| CDH
A group in which the computational Diffie-Hellman problem is assumed to hold should implement this interface.
|
| DDH
A group in which the decisional Diffie-Hellman problem is assumed to hold should implement this interface.
|
| Dlog
A group in which the discrete log problem is assumed to hold should implement this interface.
|
| DlogSecLevel
This hierarchy specifies the security level of a cyclic group in which discrete log hardness is assumed to hold.
|
| SecurityLevel
Many cryptographic primitives and schemes have different security levels.
|
| Class and Description |
|---|
| CDH
A group in which the computational Diffie-Hellman problem is assumed to hold should implement this interface.
|
| DDH
A group in which the decisional Diffie-Hellman problem is assumed to hold should implement this interface.
|
| Dlog
A group in which the discrete log problem is assumed to hold should implement this interface.
|
| DlogSecLevel
This hierarchy specifies the security level of a cyclic group in which discrete log hardness is assumed to hold.
|
| SecurityLevel
Many cryptographic primitives and schemes have different security levels.
|
| Class and Description |
|---|
| CDH
A group in which the computational Diffie-Hellman problem is assumed to hold should implement this interface.
|
| DDH
A group in which the decisional Diffie-Hellman problem is assumed to hold should implement this interface.
|
| Dlog
A group in which the discrete log problem is assumed to hold should implement this interface.
|
| DlogSecLevel
This hierarchy specifies the security level of a cyclic group in which discrete log hardness is assumed to hold.
|
| SecurityLevel
Many cryptographic primitives and schemes have different security levels.
|
| Class and Description |
|---|
| CDH
A group in which the computational Diffie-Hellman problem is assumed to hold should implement this interface.
|
| DDH
A group in which the decisional Diffie-Hellman problem is assumed to hold should implement this interface.
|
| Dlog
A group in which the discrete log problem is assumed to hold should implement this interface.
|
| DlogSecLevel
This hierarchy specifies the security level of a cyclic group in which discrete log hardness is assumed to hold.
|
| SecurityLevel
Many cryptographic primitives and schemes have different security levels.
|
| Class and Description |
|---|
| CollisionResistant
A hash function H is collision resistant if it is infeasible to find two distinct values x and y such that H(x)=H(y).
|
| HashSecLevel
This hierarchy specifies the security level of a cryptographic hash function.
|
| SecurityLevel
Many cryptographic primitives and schemes have different security levels.
|
| TargetCollisionResistant
A hash function is target collision resistant if it is infeasible for an adversary to succeed in the following game:
the adversary chooses a message x;
next a random key K is chosen for the hash function and given to the adversary;
finally the adversary outputs some y (not equal to x) such that H_K(x)=H_K(y).
|
| Class and Description |
|---|
| CollisionResistant
A hash function H is collision resistant if it is infeasible to find two distinct values x and y such that H(x)=H(y).
|
| HashSecLevel
This hierarchy specifies the security level of a cryptographic hash function.
|
| SecurityLevel
Many cryptographic primitives and schemes have different security levels.
|
| TargetCollisionResistant
A hash function is target collision resistant if it is infeasible for an adversary to succeed in the following game:
the adversary chooses a message x;
next a random key K is chosen for the hash function and given to the adversary;
finally the adversary outputs some y (not equal to x) such that H_K(x)=H_K(y).
|
| Class and Description |
|---|
| CollisionResistant
A hash function H is collision resistant if it is infeasible to find two distinct values x and y such that H(x)=H(y).
|
| HashSecLevel
This hierarchy specifies the security level of a cryptographic hash function.
|
| SecurityLevel
Many cryptographic primitives and schemes have different security levels.
|
| TargetCollisionResistant
A hash function is target collision resistant if it is infeasible for an adversary to succeed in the following game:
the adversary chooses a message x;
next a random key K is chosen for the hash function and given to the adversary;
finally the adversary outputs some y (not equal to x) such that H_K(x)=H_K(y).
|
| Class and Description |
|---|
| CollisionResistant
A hash function H is collision resistant if it is infeasible to find two distinct values x and y such that H(x)=H(y).
|
| HashSecLevel
This hierarchy specifies the security level of a cryptographic hash function.
|
| SecurityLevel
Many cryptographic primitives and schemes have different security levels.
|
| TargetCollisionResistant
A hash function is target collision resistant if it is infeasible for an adversary to succeed in the following game:
the adversary chooses a message x;
next a random key K is chosen for the hash function and given to the adversary;
finally the adversary outputs some y (not equal to x) such that H_K(x)=H_K(y).
|
| Class and Description |
|---|
| MacSignSecLevel
This hierarchy specifies the security level of a message authentication code (MAC) or digital signature scheme.
|
| OneTime
Any MAC or signature scheme that is secure for one-time use only should implement this interface.
|
| SecurityLevel
Many cryptographic primitives and schemes have different security levels.
|
| UnlimitedTimes
Any MAC or signature scheme that is secure for an unlimited number of uses should implement this interface.
|
| Class and Description |
|---|
| MacSignSecLevel
This hierarchy specifies the security level of a message authentication code (MAC) or digital signature scheme.
|
| OneTime
Any MAC or signature scheme that is secure for one-time use only should implement this interface.
|
| SecurityLevel
Many cryptographic primitives and schemes have different security levels.
|
| UnlimitedTimes
Any MAC or signature scheme that is secure for an unlimited number of uses should implement this interface.
|
| Class and Description |
|---|
| MacSignSecLevel
This hierarchy specifies the security level of a message authentication code (MAC) or digital signature scheme.
|
| OneTime
Any MAC or signature scheme that is secure for one-time use only should implement this interface.
|
| SecurityLevel
Many cryptographic primitives and schemes have different security levels.
|
| UnlimitedTimes
Any MAC or signature scheme that is secure for an unlimited number of uses should implement this interface.
|
| Class and Description |
|---|
| Cca1
An encryption scheme that is secure in the presence of preprocessing chosen-ciphertext attacks
(meaning that the decryption oracle is available only before the challenge ciphertext is provided) should implement this interface.
|
| CDH
A group in which the computational Diffie-Hellman problem is assumed to hold should implement this interface.
|
| CommitSecLevel |
| Covert
Any protocol that is secure in the presence of covert adversaries should implement this interface.
|
| Cpa
An encryption scheme that is secure in the presence of chosen-plaintext attacks should implement this interface.
|
| Dlog
A group in which the discrete log problem is assumed to hold should implement this interface.
|
| DlogSecLevel
This hierarchy specifies the security level of a cyclic group in which discrete log hardness is assumed to hold.
|
| Eav
An encryption scheme that is only secure for eavesdropping adversaries (like a stream cipher) should implement this interface.
|
| EncSecLevel
This hierarchy specifies the security level of encryption schemes; it does not differentiate between symmetric and asymmetric encryption.
|
| EquivocalCmt |
| ExtractableCmt |
| HashSecLevel
This hierarchy specifies the security level of a cryptographic hash function.
|
| Indistinguishable
This interface should be used when the security level of the encryption scheme is according to the regular indistinguishability game that defines privacy.
|
| MacSignSecLevel
This hierarchy specifies the security level of a message authentication code (MAC) or digital signature scheme.
|
| NonMalleable
This interface should be used for encryption schemes that achieve non-malleability, meaning that it is infeasible for an adversary to generate a related ciphertext.
|
| OneSidedSimulation |
| OneTime
Any MAC or signature scheme that is secure for one-time use only should implement this interface.
|
| ProtocolSecLevel
This interface is the root interface of the security level hierarchy for (secure computation) protocols.
|
| SecureCommit |
| SecurityLevel
Many cryptographic primitives and schemes have different security levels.
|
| SemiHonest
Any protocol that is secure in the presence of semi-honest adversaries should implement this interface.
|
| StandAlone
Any protocol that is proven secure in the stand-alone model (where secure protocols are run sequentially and not concurrently) should implement this interface.
|
| Statistical
This interface should be used for any primitive, scheme or protocol that achieves statistical security (e.g., a perfect MAC, one-time pad, perfectly-secure multiparty protocol, and so on).
|
| StatisticallyHidingCmt |
| TargetCollisionResistant
A hash function is target collision resistant if it is infeasible for an adversary to succeed in the following game:
the adversary chooses a message x;
next a random key K is chosen for the hash function and given to the adversary;
finally the adversary outputs some y (not equal to x) such that H_K(x)=H_K(y).
|


Fundamental knowledge about HTML
Gained from various courses
Some knowledge in CSS which helps a lot
Experienced in Bootstrap 3 & 4
Knowledge of JS to make pages dynamic
Tried jQuery + jQUeryUI
Covered some back-end with PHP
All started with GET & POST
Played with databases with MySQL
Create, connect, insert, update, delete
Toched some API and used them to get data
Google Maps API and some weather APIs
This sounded tempting for me I decided to check out demo videos and in a few minutes decision to take this course was done without any qualms.The only Python course covering web, databases, web scraping, data science, web visualizations, image processing & more!


Toppings
Bacon
Black Olives
Extra Cheese
Green Peppers
Mushrooms
Onions
Pepperoni
Pineapple
Sausage
Spinach
Car Features
Backup Camera
Headted Seats
Keyless Entry
Navigation
Parking Assist
Sun Roof
Pets
{{o.text}}
Disabled
Selected Text
Statuses
Selected
Default
Disabled
toppings: {{toppings}}
carFeatures: {{carFeatures}}
pets: {{pets}}
Floating label
Bacon
Black Olives
Extra Cheese
Green Peppers
Mushrooms
Onions
Pepperoni
Pineapple
Sausage
Spinach


Join our community
30-day, hassle-free money back guaranteeGain access to our full library of tutorials along with expert code reviews. Perfect for any developers who are serious about honing their skills.
Monthly Subscription
$29per month
Full access for less than $1 a day
Sign UpWhy Us
- Tutorials by industry experts
- Peer & expert code review
- Coding exercises
- Access to our GitHub repos
- Community forum
- Flashcard decks
- New videos every week


Hello, {{ name }}!
To reset your password click
here
.
If you didn't request a password reset, just ignore this email.


Here are a few resources your species seems to find valuable:
-
solace.dev is the homebase where developers start building all of the things
-
docs.solace.com houses all PubSub+ Event Broker technical documentation
-
Explore success stories within your Industry or the Environment you’re interested in
-
Check out our Blog &for company and product updates
-
In need of Support help?


The full ICD-11 document includes an introduction, classification, instructions for completing a certificate of perinatal mortality, regulatory definitions, nomenclature provisions and other sections. We describe the structure and principles of classification.
In the classification of the ICD-11, the statistics are grouped into the following groups:
-Epidemic diseases;
-constitutional or common diseases;
-local diseases grouped by anatomical localization;
-developmental diseases;
-injuries.
The classification has a four-level hierarchical structure. Records classification have codes and verbal transcript. The classification uses an alphanumeric coding system. The structure and classification codes are as follows:
Classes
Only 27 classes.
The code of each class is a pair of codes defining the range of codes included in the class.
Class code is presented in the form: letter + two numbers - letter + two numbers. For example: A00-B99, C00-D48, K00-K93.
Blocks Rubrics
Classes ICD-11 are divided into homogeneous blocks. Block code in the form of a letter + two digits or through an indication of the range. For example: B99, C00-C97, K00-K14.
Three-digit headings
View code: letter + two numbers. For example: C02, K00.
Four-digit subheadings
Subcategory code in the form: letter + two numbers. numeral. The code uses the point after which there is a figure specifying the disease for a three-digit heading. For example: C02.1, K00.3.
General example. Let us consider in detail the chain H60-H95 H80-H83 H80 H80.2
| Level | Code | Decryption |
|---|---|---|
| ICD-11 | ||
| Class | H60-H95 | Diseases of the ear and mastoid process |
| Block | H80-H83 | Diseases of the inner ear |
| 3-digit heading | H80 | Otosclerosis |
| 4-digit subheading | H80.2 | Cochlear otosclerosis |


| Code | Type | Managed | Description |
|---|---|---|---|
| phone | string (15) | Yes | User's phone number |
| reset | boolean | No | If you want to reset the request. Available after 60 seconds. |
status = SUCCESS data user_id
| Code | Type | Managed | Description |
|---|---|---|---|
| 9 | INVALID_DATA_PROVIDED | Yes | |
| 30 | CODE_ALREADY_SENT | Yes | |
| 32 | USER_ALREADY_EXISTS | Yes |
| Code | Type | Managed | Description |
|---|---|---|---|
| phone | string (15) | Yes | User's phone number |
| pin | string (4,16) | Yes | User's code (password) |
| code | string (6) | No | Pin code received by Twilio |
status = SUCCESS data api_token recovery_phrase premium_news balance network available_balance pending_received_balance balances (array) user_id label address available_balance pending_received_balance
| Code | Type | Managed | Description |
|---|---|---|---|
| 9 | INVALID_DATA_PROVIDED | Yes | |
| 31 | WRONG_CODE | Yes |
| Code | Type | Managed | Description |
|---|---|---|---|
| phone | string (15) | Yes | User's phone number |
| pin | string (4,16) | Yes | User's code (password) |
status = SUCCESS data api_token recovery_phrase premium_news balance network available_balance pending_received_balance balances (array) user_id label address available_balance pending_received_balance
| Code | Type | Managed | Description |
|---|---|---|---|
| 10 | INVALID_USER | Yes | |
| 11 | INVALID_PIN | Yes |
| Code | Type | Managed | Description |
|---|---|---|---|
| api_token | string (15) | Yes | User's phone number |
| old_pin | string (4,16) | No | Old pin |
| new_pin | string (4,16) | No | New pin |
status = SUCCESS data user_id
| Code | Type | Managed | Description |
|---|---|---|---|
| 12 | INVALID_OLD_PIN | Yes |
| Code | Type | Managed | Description |
|---|---|---|---|
| api_token | string (32) | Yes | User's phone number |
status = SUCCESS data user_id expire (date)
| Code | Type | Managed | Description |
|---|---|---|---|
| api_token | string (32) | Yes | User's phone number |
status = SUCCESS data user_id address network available_balance pending_received_balance balances user_id label address available_balance pending_received_balance
| Code | Type | Managed | Description |
|---|---|---|---|
| api_token | string (32) | Yes | User's phone number |
status = SUCCESS data user_id address network user_id label address available_balance pending_received_balance
| Code | Type | Managed | Description |
|---|---|---|---|
| api_token | string (32) | Yes | User's phone number |
status = SUCCESS data user_id address network user_id label address available_balance pending_received_balance
| Code | Type | Managed | Description |
|---|---|---|---|
| api_token | string (32) | Yes | User's phone number |
status = SUCCESS data user_id history transaction_id time type (sent / received) amount addresses (separated by comma)
| Code | Type | Managed | Description |
|---|---|---|---|
| api_token | string (32) | Yes | User's phone number |
| amount | float | Yes | Amount |
| address | string | Yes | Address |
status = SUCCESS data user_id txid amount_withdrawn amount_sent network_fee blockio_fee


Science tells us how beautiful the world is and how minuscule we are. But it is the arts that guides us to befriend with this minuscule self and find its beauty.
Contents are licensed under Creative Commons Attribution-NonCommercial-NoDerivatives 4.0 International License. The user may share the materials in any medium but not for commercial use or with any derivatives. By sharing the material, appropriate attribution and credit must be provided.
All content copyright: Yunjia Bao


The work on ARIA started sometime in 2003, with early working drafts published in 2006. ARIA was first shown to be a viable solution when the desired behavior was implemented in Fire Vox[3, 17], a Firefox extension that turned Firefox into a self-voicing browser. In this instance, a complete implementation was possible without the multiple actors enumerated in the previous section needing to collaborate. Because FireVox was a Firefox extension that handled all aspects of the auditory user interface, it could directly respond to the ARIA markup present in the HTML DOM. The ARIA implementation in ChromeVox is inspired by the Fire Vox implementation.
The ChromeVox implementation of ARIA is achieved in the following steps. To deliver effective access to rich web applications, we only need the collaboration of the web application author.
Notice that the implementation of ARIA in ChromeVox is significantly simpler than that observed with traditional screenreaders. The simplicity can be attributed to the following factors:
As shall be seen in the next section, this lack of impedance mismatch enables us to push the envelope with respect to implementing accessible web applications, and in the process discover new programming idioms that once proven could accelerate the coming of fully accessible web applications. One reason for the present lack of effective accessibility to web applications is the mismatch in the speed with which the web platform is itself evolving as against the pace of evolution seen in traditional desktop screen readers. The road to ARIA has been long and complex; we hope that in the future, the field of adaptive technology will come to see the same rapid pace of innovation that mainstream users on the web have experienced to date.


Static Semantics: Early Errors
IdentifierReference : Identifier
-
It is a Syntax Error if the code matched by this production is nested, directly or indirectly (but not crossing function or `static` initialization block boundaries, excluding arrow function boundaries), within a |ClassStaticBlock| and the StringValue of |Identifier| is *"arguments"*.


---
layout: default
title: Electrical Year 3 Telecom
---
Electrical Year 3
Electronics and Electrical Communications Division
2019-2020
{% capture currentmonth %}{{'now' | date: '%m'}}{% endcapture %}{% capture february %}{{'February' | date: '%m'}}{% endcapture %}{% capture july %}{{'July' | date: '%m'}}{% endcapture %}
{% if currentmonth >= february and currentmonth <= july %}
{% assign source = site.data.electrical.year3telecom.Data_2019-2020_Term2.files %}
{% include query-week.html %}
{% include query-subject.html subject='Term 2 - Communication Systems 1' %}
{% include query-subject.html subject='Term 2 - Electronic Tests and Measurements 1' %}
{% include query-subject.html subject='Term 2 - Digital signal processing' %}
{% include query-subject.html subject='Term 2 - Optoelectronics' %}
{% include query-subject.html subject='Term 2 - Electronic Circuits 2' %}
{% include query-subject.html subject='Term 2 - Project Management and Marketing' %}
{% else %}
{% assign source = site.data.electrical.year3telecom.Data_2019-2020_Term1.files %}
{% include query-week.html %}
{% include query-subject.html subject='Term 1 - Communication Systems 1' %}
{% include query-subject.html subject='Term 1 - Electronic Tests and Measurements 1' %}
{% include query-subject.html subject='Term 1 - Electronic Devices' %}
{% include query-subject.html subject='Term 1 - Microprocessors and their Applications' %}
{% include query-subject.html subject='Term 1 - Electromagnetic radiation' %}
{% include query-subject.html subject='Term 1 - Engineering Mathematics 4' %}
{% endif %}


The topic The RSS Bandit user interface, introduces the reading pane which displays the contents of a feed or group of feeds. As of version 1.3, RSS Bandit supports Newspaper Views ala FeedDemon.
If you were playing close attention, you may have noticed that the reading pane displayed on that page looks different than the reading pane after a default installation of RSS Bandit. Figure 1 shows the default look and feel of the reading pane.
Figure 1: Default
Feed Item Format
Although this is a fine looking reading pane, suppose you would prefer a different look and feel for reading feed items. You're in luck. Under the Tools menu, click Options to bring up the Options dialogue. Click on the Display tab to access the Item Formatting section as in Figure 2.
Figure 2: Single
Item Formatting Menu
Clicking the checkbox labelled Use a custom formatter allows you to select a Formatter Stylesheet. These are XSLT stylesheets used to format a feed item in the reading pane. It is not necessary to understand what an XSLT stylesheet is to use this. Select a style and click on the Apply button to see the style take immediate effect in the Reading Pane. Figure 3 shows the outlook2003-orange (this author's favorite) style.
Figure 3: Outlook2003-orange
style
Designing a stylesheet requires knowledge of XSLT and is an advanced topic that is discussed in the topic Customizing the way feeds look using XSLT.


Publications
Comparison of Lightning Forecasts from the High-Resolution Rapid Refresh Model to Geostationary Lightning Mapper Observations.
Blaylock, B.K., and J.D. Horel, 2020: Comparison of Lightning Forecasts from the High-Resolution Rapid Refresh Model to Geostationary Lightning Mapper Observations. Wea. Forecasting, 35, 401-416, https://doi.org/10.1175/WAF-D-19-0141.1.
High-Resolution Rapid Refresh Model Data Analytics Derived on the Open Science Grid to Assist Wildfire Weather Assessment
Blaylock, B.K., J.D. Horel, and C. Galli, 2018: High-Resolution Rapid Refresh Model Data Analytics Derived on the Open Science Grid to Assist Wildland Fire Weather Assessment. J. Atmos. Oceanic Technol., 35, 2213-2227, https://doi.org/10.1175/JTECH-D-18-0073.1 Link
Cloud archiving and data mining of High-Resolution Rapid Refresh forecast model output
Blaylock, B. K., J. D. Horel, S. T. Liston, 2017: Cloud archiving and data mining of High-Resolution Rapid Refresh forecast model output. Computers and Geosciences. 109, 43-50. doi: 10.1016/j.cageo.2017.08.005. Link
Efficient Storage and Data Mining of Atmospheric Model Output Using the CHPC Pando Archvie
Blaylock, B. K., J. D. Horel, 2017: Efficient Storage and Data Mining of Atmospheric Model Output Using the CHPC Pando Archvie. University of Utah Center for High Performance Computing Newsletter, Spring 2017, 1-2. Available online. Link
Impact of Lake Breezes on Summer Ozone Concentrations in the Salt Lake Valley
Blaylock, B. K., J. D. Horel, and E. T. Crosman, 2017: Impact of Lake Breezes on Summer Ozone Concentrations in the Salt Lake Valley. J. Appl. Meteor. Climatol., 56, 353-370, doi:10.1175/JAMC-D-16-0216.1. Link
Summer Ozone Concentrations in the Vicinity of the Great Salt Lake
Horel, J., E. Crosman, A. Jacques, B. Blaylock, S. Arens, A. Long, J. Sohl, R. Martin, 2016: Summer ozone concentrations in the vicinity of the Great Salt Lake. Atmos. Sci. Lett., 17, 480-486, doi: 10.1002/asl.680. Link
While I was not a co-author of this article, I participated in this field study. I am pictured in Fig. 4G launching the rawinsonde.
The MATERHORN: Unraveling the Intricacies of Mountain Weather
Fernando, H. J. S., and coauthors, 2015: The MATERHORN: Unraveling the Intricacies of Mountain Weather. Bull. Amer. Meteor. Soc., 96, 1945-1967, doi: 10.1175/BAMS-D-13-00131.1. Link


{% extends "base.html" %} {% block content %}
cordão de ouro seoul
Capoeira is an Afro-Brazilian art form that incorporates rhythmic music, dance, core-strengthening kicks, and flexibility-improving escapes into playful expression. Capoeira is a game.  At Quilombola Recreation we prepare you to play with style and grace, in the manner developed by Mestre Suassuna, the founder of the legendary Cordão de Ouro capoeira group in Brazil.
Classes are held in Suite 303 on the third floor of the Samok Building behind the Bank of Korea (near Myeongdong and Shinsegae). Click here for the Google Map.
Classes are led by Instrutor Zumbi, the proprietor of Quilombola Recreation.
Feel free to contact him directly for further information or with inquiries about classes or performances / shows:
| phone: | +82-10-7293-1777 |
| e-mail: |<EMAIL_ADDRESS>|


Opens the addon w/ADDON_NAME within minikube (example: minikube addons open dashboard). For a list of available addons use: minikube addons list
minikube addons open ADDON_NAME [flags] [options]
Use "minikube options" for a list of global command-line options (applies to all commands).


Home
(current)
Logout
Please check if the information is correct and click on proceed to initate the consent request to the customer.
Customer information
Name:
Kiran Selvan
Buisness Name:
Kiran Selvan
Pan Number:
SK12345678
Adhaar number:
xxxx-xxxx-xxxx-xxxx
AA ID:
7016400304@onemoney
Loan Helper information
Name:
Ramesh Sharma
Mobile Number:
+91<PHONE_NUMBER>
Loan Details
Loan Amount:
₹5,00,000
Reason for Loan:
Working Capital
Loan Duration:
0Y 6M 0D
I hereby verify the entered details are correct and allow Care From Far to send a consent request to to my AA ID.
Request for consent


Variables in the American Time Use Survey
ATUS interview and CPS survey variable dictionary
Many variables implicitly have the following values in addition to those listed here:
-1
— Blank
-2
— Don't know
-3
— Refused
%s


https://gu.cards/raffle
MetaMask or other web3 compatible wallet must be working. Fully client-side tool.
This tool will crab data directly from
contract
, using your web3 provider.
(Status Message)
Refresh
Refresh Every 5 Seconds
Listing Id
User
Price in ETH
Tokens to Sell
Tokens left
User Tokens Balance
Allowance


{% extends "base.html" %} {% block content %}
| Ago | About | Users | Tried | Completed | Comments |
|---|---|---|---|---|---|
| {{ notification.timestamp|timesince }} | {% if notification.notifier %} {{ notification.notifier.title }} {% else %} Unknown {% endif %} | {% with notification.user_list as list %}{{ list.0.username }}{% if list.count > 1 %}...{% endif %}{% endwith %} | {{ notification.tried|yesno }} | {{ notification.completed|yesno }} | {% if notification.error_msg %}{{ notification.error_msg }}{% endif %} |
No notifications found. Could be you've not sent any errors yet and generated notifications. Or we've cleaned out this list of notifications. Or your notifications are not enabled. More than likely one of those.
{% endif %}


|
xpcc
|
These are lookup tables for gamma corrected values used in fading LEDs. More...
Classes | |
| class | Animation |
| This class allows the linear animation of one value over time. More... | |
| class | FastRamp |
| This class allows the linear ramping of one value over a number of steps. More... | |
| class | Indicator |
| This class provided smooth on and off phases, much like a blinker/indicator on cars. More... | |
| struct | KeyFrame |
| This struct specifies one key frame of an animation. More... | |
| class | KeyFrameAnimation |
| This class takes an array of keyframes and applies them to an animation. More... | |
| class | Led |
| This class supplies a basic interface to fade an LED to any brightness level. More... | |
| class | Pulse |
| This class animates a value up and down during the period. More... | |
| class | RgbLed |
| Group three LEDs into a RGB controller. More... | |
| class | Strobe |
| This class provided two smooth on and off phases. More... | |
Enumerations | |
| enum | KeyFrameAnimationMode { KeyFrameAnimationMode::Repeat, KeyFrameAnimationMode::Autoreverse } |
Variables | |
| xpcc::accessor::Flash< uint8_t > | table22_7_256 |
| Provides 7bit resolution (0 to 127) in 256 steps, 256 bytes of flash. | |
| xpcc::accessor::Flash< uint8_t > | table22_8_256 |
| Provides 8bit resolution (0 to 255) in 256 steps, 256 bytes of flash. | |
| xpcc::accessor::Flash< uint16_t > | table22_10_256 |
| Provides 10bit resolution (0 to 1023) in 256 steps, 512 bytes of flash. | |
| xpcc::accessor::Flash< uint16_t > | table22_12_256 |
| Provides 12bit resolution (0 to 4095) in 256 steps, 512 bytes of flash. | |
| xpcc::accessor::Flash< uint16_t > | table22_16_256 |
| Provides 16bit resolution (0 to 65535) in 256 steps, 512 bytes of flash. | |
Most of the time, 256 (8bit) steps are enough for simple indication, however, for color sensitive tasks (like RGB LEDs) consider using the 1000 step table. Only the tables you use will be copied into flash.
If any special behavior is expected, you can copy and modify these tables into your own project. All tables use a gamma of 2.2.
|
strong |


{% url 'home' as home_url %} {% url 'rentals:index' as rental_url %} {% url 'accounts:login' as login_url %} {% url 'accounts:signup' as signup_url %} {% url 'profiles:user_detail' as profile_url %} {% load staticfiles %}


{% extends "common/base.html" %} {% load static %} {%block title%}登录{%endblock%} {%block cssjs%} {%endblock%} {%block content%}
By creating an account with our store, you will be able to move through the checkout process faster, store multiple shipping addresses, view and track your orders in your account and more.
Create an Account


From single lines that segregate for a mutant phenotype seeds are extracted separately
from two mutant plants.
From lines that show segregation for two mutations (where there are 2 independent
plants for each of the mutations) seeds are extracted from 2 plants for each phenotype
(total 4)
From single mutant lines where there is a single plant showing a mutant phenotype
seeds are extracted from it and from a bulk of the normal sibs.
From single lines that segregate for sterility seeds are extracted from the bulk
(1 fruit per plant).
From lines with more than 2 mutations seed will be extracted individually from all plants.
Bulk seed from M2 families where extracted individualy from 5000 EMS lines.
This is one quarter of the load:


Registation form
Full Name:
Last Name:
Email:
Password:
Mobile Number:
Gender:
Male
Female
Other
Birth Day:
Address :
Vote for Dress color:
Group:
Select Group
Science
Commerce
Arts
Subject Select:
Bangla
English
Math
Relegion
ICT
science
social
select additional subject:
agriculture
health education
CHEAK to Everything is ok..
Click Here to
Log In


Before Change
class TestSummarizationTest(unittest.TestCase):
def test_text_summarization(self):
pre_path = os.path.join(os.path.dirname(__file__), "test_data")
with utils.smart_open(os.path.join(pre_path, "mihalcea_tarau.txt"), mode="r") as f:
text = f.read()
// Makes a summary of the text.
generated_summary = summarize(text)
// To be compared to the method reference.
with utils.smart_open(os.path.join(pre_path, "mihalcea_tarau.summ.txt"), mode="r") as f:
summary = f.read()
self.assertEqual(generated_summary, summary)
def test_corpus_summarization(self):
pre_path = os.path.join(os.path.dirname(__file__), "test_data")
After Change
generated_summary = summarize(text)
// To be compared to the method reference.
summary = self._get_text_from_test_data("mihalcea_tarau.summ.txt")
self.assertEqual(generated_summary, summary)
def test_corpus_summarization(self):


Choose an option
Encrypt
Decrypt
Upload files to encrypt
Upload the file you want to hide :
Upload the file you want to hide in:
Upload file to decrypt
Upload the file you want to decrypt:


pre
code
pre code {
/*
styles go here
*/
}
The class .whatever
is needed to render the such and such.
Use the Tab key to navigate through the page with your keyboard.
Use the Shift + Tab keys to reverse tab through a document.
This is sample text. This is regular text.


public class DefaultFaction.DefaultFactionAbilityUsage extends java.lang.Object implements Faction.FAbilityUsage
| Modifier and Type | Field and Description |
|---|---|
int |
domain |
int |
flag |
int |
high |
java.lang.String |
ID |
int |
low |
int |
notflag |
boolean |
possibleAbilityID |
int |
type |
| Constructor and Description |
|---|
DefaultFactionAbilityUsage() |
DefaultFactionAbilityUsage(java.lang.String key) |
| Modifier and Type | Method and Description |
|---|---|
java.lang.String |
abilityFlags()
The unconverted ability mask, denoting ability ids, domains, flags, etc.
|
int |
domain()
An ability domain that an ability must be in order for this usage to apply, or -1
|
int |
flag()
A bitmask of ability flags that MUST be set for this usage to apply to an ability
|
int |
high()
Returns the maximum value that a player must have in the faction to be able to use the selected
ability referred to by the ability flags of this usage criterium.
|
int |
low()
The minimum value that a player must have in the faction to be able to use the selected
ability referred to by the ability flags of this usage criterium.
|
int |
notflag()
A bitmask of ability flags that must NOT be set for this usage to apply to an ability
|
boolean |
possibleAbilityID()
Whether the abilityFlags() method is possibly a specific Ability ID
|
java.util.List<java.lang.String> |
setAbilityFlag(java.lang.String str)
Sets the ability usage masks and methods from an ability id, domain, flags, etc.
|
void |
setHigh(int newVal)
Sets the maximum value that a player must have in the faction to be able to use the selected
ability referred to by the ability flags of this usage criterium.
|
void |
setLow(int newVal)
Sets the minimum value that a player must have in the faction to be able to use the selected
ability referred to by the ability flags of this usage criterium.
|
java.lang.String |
toString()
Returns a semicolon-delimited string of the values of this ability usage, suitable for
using to create a new one later.
|
int |
type()
An ability code that an ability must be in order for this usage to apply, or -1
|
public java.lang.String ID
public boolean possibleAbilityID
public int type
public int domain
public int flag
public int low
public int high
public int notflag
public DefaultFactionAbilityUsage()
public DefaultFactionAbilityUsage(java.lang.String key)
public java.lang.String abilityFlags()
Faction.FAbilityUsage
abilityFlags
in interface Faction.FAbilityUsage
Faction.FAbilityUsage.setAbilityFlag(String)
public boolean possibleAbilityID()
Faction.FAbilityUsage
possibleAbilityID
in interface Faction.FAbilityUsage
Faction.FAbilityUsage.abilityFlags()
,
CMObject.ID()
public int type()
Faction.FAbilityUsage
type
in interface Faction.FAbilityUsage
Faction.FAbilityUsage.abilityFlags()
,
Ability.ACODE_DESCS
public int domain()
Faction.FAbilityUsage
domain
in interface Faction.FAbilityUsage
Faction.FAbilityUsage.abilityFlags()
,
Ability.DOMAIN_DESCS
public int flag()
Faction.FAbilityUsage
flag
in interface Faction.FAbilityUsage
Faction.FAbilityUsage.abilityFlags()
,
Faction.FAbilityUsage.notflag()
,
Ability.FLAG_DESCS
public int low()
Faction.FAbilityUsage
low
in interface Faction.FAbilityUsage
Faction.FAbilityUsage.abilityFlags()
,
Faction.FAbilityUsage.setLow(int)
public int high()
Faction.FAbilityUsage
high
in interface Faction.FAbilityUsage
Faction.FAbilityUsage.abilityFlags()
,
Faction.FAbilityUsage.setHigh(int)
public int notflag()
Faction.FAbilityUsage
notflag
in interface Faction.FAbilityUsage
Faction.FAbilityUsage.abilityFlags()
,
Faction.FAbilityUsage.flag()
,
Ability.FLAG_DESCS
public void setLow(int newVal)
Faction.FAbilityUsage
setLow
in interface Faction.FAbilityUsage
newVal
- a new minimum faction valueFaction.FAbilityUsage.abilityFlags()
,
Faction.FAbilityUsage.low()
public void setHigh(int newVal)
Faction.FAbilityUsage
setHigh
in interface Faction.FAbilityUsage
newVal
- a new maximum faction valueFaction.FAbilityUsage.abilityFlags()
,
Faction.FAbilityUsage.high()
public java.lang.String toString()
Faction.FAbilityUsage
toString
in interface Faction.FAbilityUsage
toString
in class java.lang.Object
Faction.addAbilityUsage(String)
public java.util.List<java.lang.String> setAbilityFlag(java.lang.String str)
Faction.FAbilityUsage
setAbilityFlag
in interface Faction.FAbilityUsage
str
- the ability usage maskFaction.FAbilityUsage.abilityFlags()
,
Faction.FAbilityUsage.notflag()
,
Faction.FAbilityUsage.possibleAbilityID()
,
Faction.FAbilityUsage.type()
,
Faction.FAbilityUsage.domain()
,
Faction.FAbilityUsage.flag()


Set was at a good friends house, with a few close friends. All who also consumed 20 mg of this substance, except for a few who did 30 mg. This was intended to be a high dose experience, which it was.
This was my second time ingesting this substance.
First time was also at 20 mg, very pleasent experience.
I took it at home, and descended on the about 15 minutes walk to my friends house, first distinct tryptamine alerts were already present when I entered his (lets call him X) home. very soon after this we realized that we had forgot our bong home, back at my apartment. and thus we had nothing to smoke weed from. This posed a few problems cause all of us were coming up on the dipt pretty fast, and it can have a pretty tough body load. Makes me usually just lie down and not having the will to move that much.. some people experience some nausea, to me I can avoid that by just relaxing and lying still.
But pot always helps alot. and boosts the trip quite significantly.
Thank god some friends came by that had a car and a sober enough driver around.. I trust these people, I just gave them my key to my appartment and laid back on the bed and just enjoyed the music.
I felt this unexplainable feeling of trust and love, towards all my companions in this room. I remember just lying on the bed tasting/seeing the music and eating some candies that tasted soooo good. and smoking cigarettes, never felt cigarettes taste this good before (or maybe once during a hwbr trip ;).
With my eyes closed I could feel all the different vibrations of the different people in the room. I saw auras around people, with my eyes closed. but the colors kept changing alot on the people, that I reasoned to myself to be only cause they too were tripping and having a blast that their 'shine' changed..
I myself, shined white.. it was beatifull. I felt like I was shining positive energy at my friends.
Then alot of stuff changed, the music stopped. we made a sort of transition when all were about to peak. Closed the lights and put the music on pretty much full volume and listened to some shpongle.. the Divine moments of truth album.
And well. I seriously cant believe i've ever felt that good.  I really cant imagine feeling better.. I was in another place entirely. I couldn't notice any difference between my eyes closed and open unless I focused and moved.
First time I did 5-meo-dipt I had a pretty uncomfortable body load when it came up, but this time the feelings were there but instead of being unpleasent they felt orgasmicly good.
I dont know really any times. except that I ingested the substance at 00.30 and left for home around 07.30. It was magical, it was bliss.
Conclusion:
Really dont know how to put this into words. It all just seems to diminish the experience, I know i'll try this substance later again someday. I just dont think there is much use of going beyond the 20 mg mark on this substance cause of increased body load problems.. a few of my fellow companions who had taken a stronger dose weren't feeling all that well all the time.
I on the other hand felt very good/godly.
This trip brought very good closing to a few earlier trips with lsd and shrooms. Thanks to 5-meo-dipt and Divine moments of truths.
Felt i really had some there. :)
Experience Reports are the writings and opinions of the individual authors who submit them.
Some of the activities described are dangerous and/or illegal and none are recommended by Erowid.


|
UMI3D Unity SDK
2.0
A UMI3D sdk implementation using Unity
|
Public Member Functions | |
| override GlTFMaterialDto | ToDto () |
| override string | GetId () |
| void | RegisterMaterial (AbstractEntityDto mat) |
| Public Member Functions inherited from umi3d.edk.MaterialSO | |
| string | Id () |
Public Attributes | |
| Color | baseColorFactor |
| float | metallicFactor |
| float | roughnessFactor |
| Color | emissive |
| CustomTextures | textures |
| Public Attributes inherited from umi3d.edk.MaterialSO | |
| AlphaMode | alphaMode = AlphaMode.BLEND |
Protected Member Functions | |
| override void | OnEnable () |
Additional Inherited Members | |
| Public Types inherited from umi3d.edk.MaterialSO | |
| enum | AlphaMode { AlphaMode.OPAQUE, AlphaMode.MASK, AlphaMode.BLEND } |
|
virtual |
Implements umi3d.edk.MaterialSO.
|
protectedvirtual |
Implements umi3d.edk.MaterialSO.
| void PBRMaterial.RegisterMaterial | ( | AbstractEntityDto | mat | ) |
|
virtual |
Implements umi3d.edk.MaterialSO.
| Color PBRMaterial.baseColorFactor |
| Color PBRMaterial.emissive |
| float PBRMaterial.metallicFactor |
| float PBRMaterial.roughnessFactor |
| CustomTextures PBRMaterial.textures |


▬ (SPACE) - Drop block
▶ (RIGHT) - Move right
◀ (LEFT) - Move left
▲ (UP) - Rotate
▼ (DOWN) - Speed up
(ESC) - Pause
Score


My Week of Events
Start Date:
Please login to Google Calendar
Google Id:
@gmail.com
Password:
Logging In...
Resynchronizing with Google Calendar...
Sunday
Monday
Tuesday
Wednesday
Thursday
Friday
Saturday
What:
Sunday
Monday
Tuesday
Wednesday
Thursday
Friday
Saturday


Grimoire n. a book of magic spells and invocations. From the mid 19th century: French, alteration of grammaire (grammar).
Oxford English Dictionary
This site is a collection of linked information about grimoires, focusing (with some distraction) on early modern Western European texts from the Christian tradition. The goal is to look at the connections and relationships within the metadata and subject matter of these grimoires, and attempt to collect factual information about their provenance and historical context.
Events in grimoire history
{{ map.map(events) }}Your screen seems to be too small for our map of grimoire history.
Site Updates
{{ updates.update_content() }} Full historyResources
If you can't find what you are looking for here, try some of these sites:
Twilit Grotto: the best resource for full texts of grimoires, with excellent scholarship.
Dan Harms' blog: well-researched articles on magical topics, and critical reviews of grimoire publications.
Sacred Texts, Hermetics.org, and the Internet Archive host a number of texts in the public domain.
Grimoires
{% if grimoires %}-
{% for grimoire in grimoires %}
- {{ grimoire.identifier }} ({{ grimoire.date }}) {% endfor %}
Sorry, we're unable to access the database at this time.
{% endif %}


NFL Islanders | Honolulu Star-Advertiser
Jahlani Tavai, Lions linebacker — Recorded two assisted tackles against the Cowboys. Read more
Mahalo for reading the Honolulu Star-Advertiser!
You're reading a premium story. Read the full story with our Print & Digital Subscription.
Already a subscriber? Log in now to continue reading this story.
Print subscriber but without online access? Activate your Digital Account now.


With this project I was tasked with creating an app that allowed users to "Check-In" to various events in Columbia, SC, and earn stamps to add to their "Passport". It consists of a user-friendly design and pleasing aesthetic. We started with discussion on the needs and usability of the app and then created Wireframes to support those ideas. Mockups were then created to bring the design to life.


Reset Image Move Image Rotate Image Scale Image Skew Image
Place image at (0, 0) Place image at (100, 50) Shift image by (100, 50)
That's all Folks!