Previously when setting up the sample instruction for an indirect
sampler the vec4 backend was directly passing the pseudo opcode's
src0. However vec4_visitor::visit(ir_texture *) doesn't set the
texture operation's src0 -- it's left as BAD_FILE, which when
translated into a brw_reg gives the null
Kenneth Graunke writes:
> _mesa_meta_fb_tex_blit_begin(ctx, &blit);
> + ctx->Extensions.ARB_texture_stencil8 = true;
Maybe you could put assert(ctx->Extensions.ARB_texture_stencil8==false)
just before setting it to true so that we'll definitely remember to
remove it if we eventually enable
two bytes.
Reviewed-by: Neil Roberts
- Neil
Cody Northrop writes:
> The blitter will start at a pixel's natural alignment. For PBOs, if the
> provided offset if not aligned, bits will get dropped.
>
> This change adds offset alignment check for src and dst, kicking back if
&
f you were to upload the data as GL_UNSIGNED_INT_8_8_8_8_REV
then it would be a different story.
I guess either way though the patch doesn't do any harm though and it's
good if it fixes a real-world use case.
- Neil
Neil Roberts writes:
> This patch looks good to me.
>
>
The GL side of this extension just provides an accessor via glGetIntegerv for
the value of GL_CONTEXT_RELEASE_BEHAVIOR so it is trivial to implement. There
is a constant on the context for the value of the enum which is initialised to
GL_CONTEXT_RELEASE_BEHAVIOR_FLUSH. The extension is always enabl
Previously the CreateContext method of __DriverApiRec took a set of arguments
to describe the attribute values from the window system API's
CreateContextAttribs function. As more attributes get added this could quickly
get unworkable and every new attribute needs a modification for every driver.
T
The main incentive to do this is to get the defines for the
GL_KHR_context_flush_control extension.
---
include/GLES2/gl2ext.h | 313 -
1 file changed, 310 insertions(+), 3 deletions(-)
diff --git a/include/GLES2/gl2ext.h b/include/GLES2/gl2ext.h
in
Here's a series of patches to implement GL_KHR_flush_control and
GLX_ARB_flush_control. The idea of the extension is quite simple and
just makes it so that the GL doesn't implicitly flush the context when
the context is unbound. This should be a speed improvement for
applications that are using mul
It shouldn't be necessary to flush the context within the driver
implementation because the old context is explicitly flushed in
_mesa_make_current before the driver code is reached. It is useful to only
have a single place that flushes the context when switching contexts to make
it easier to later
Implementing the extension just involves copying the release behaviour value
from the context config to the GL context's constants. The upper layers of
Mesa handles the actual flushing.
---
src/mesa/drivers/dri/i965/brw_context.c | 20 +++-
src/mesa/drivers/dri/i965/intel_screen.c
If the driver supports __DRI2_FLUSH_CONTROL then the
GLX_ARB_context_flush_control extension will now be enabled as well.
If the flush behavior attribute is passed to
glXCreateContextAttribsARB and the driver doesn't support
__DRI2_FLUSH_CONTROL then the driver should already generate the
correct e
---
glx/extension_string.c | 1 +
glx/extension_string.h | 3 ++-
2 files changed, 3 insertions(+), 1 deletion(-)
diff --git a/glx/extension_string.c b/glx/extension_string.c
index 4bef96f..e881d21 100644
--- a/glx/extension_string.c
+++ b/glx/extension_string.c
@@ -72,6 +72,7 @@ struct extension
The commit for adding the reset notification extension (90aa2486e) has
a note saying that we can assume that if the underlying provider
doesn't support the extension then it will generate BadMatch for these
attributes. This patch takes the same approach.
---
glx/createcontext.c | 15 ++
This adds the server-side parts of GLX_ARB_context_flush_control. The
corresponding client-side parts in Mesa are posted to the mesa-dev
list here:
http://lists.freedesktop.org/archives/mesa-dev/2014-October/068914.html
There is also a patch needed for glproto which I will post here too.
Apologie
---
glxtokens.h | 8
1 file changed, 8 insertions(+)
diff --git a/glxtokens.h b/glxtokens.h
index a95082e..68634ee 100644
--- a/glxtokens.h
+++ b/glxtokens.h
@@ -309,6 +309,14 @@ extern "C" {
#define GLX_CONTEXT_RESET_NOTIFICATION_STRATEGY_ARB 0x8256
#define GLX_NO_RESET_NOTIFICATION_A
---
docs/GL3.txt| 2 +-
docs/relnotes/10.4.html | 1 +
2 files changed, 2 insertions(+), 1 deletion(-)
diff --git a/docs/GL3.txt b/docs/GL3.txt
index 5adc759..3ab4b40 100644
--- a/docs/GL3.txt
+++ b/docs/GL3.txt
@@ -195,7 +195,7 @@ GL 4.5, GLSL 4.50:
GL_ARB_get_texture_sub_image
This adds the framework for the GLX flush control extension. It is advertised
if the DRI driver implements the new __DRI2_FLUSH_CONTROL extension. The GLX
attributes are converted to the appropriate DRI attributes.
---
src/glx/dri2_glx.c | 19 +--
src/glx/dri3_glx.c | 15
Adds a DRI extension which advertises that the driver can accept a new
__DRI_CTX_ATTRIB_RELEASE_BEHAVIOR attribute in the createContextAttribs
function. If the attribute is specified then it will be passed down to the
CreateContext function in the release_behavior member of
__DriverContextConfig. T
Ian Romanick writes:
> I'm a little bit skeptical of this. _mesa_make_current doesn't call
> intelMakeCurrent. intelMakeCurrent calls _mesa_make_current, and it
> calls _mesa_make_current much later in this function. By the time
> _mesa_make_current is called, a bunch of driver state has been
I wrote:
> I guess I should try to explore intelMakeCurrent in a bit more
> detail to try to determine whether it's ok not to flush.
It looks like all the code between the flush and the call to
_mesa_make_current it just operating on the new context not the old
context and it looks fairly trivial
The edge flag data on Gen6+ is passed through the fixed function hardware as
an extra attribute. According to the PRM it must be the last valid
VERTEX_ELEMENT structure. However if the vertex ID is also used then another
extra element is added to source the VID. This made it so the vertex ID is in
Ian Romanick writes:
> Hmm... There's a flag. The flag says whether a field is valid. When
> the field is valid, there is only one possible value for that field.
> This seems weird to me. If the field can have only one value, we don't
> really need it. This applies to the next patch as well.
I'm
On inspection it looks like this would potentially break
_mesa_meta_Clear when it is using GLSL because that does not save the
MESA_META_TRANSFORM state.
I wonder if MESA_META_TRANSFORM is not the right state flag for this
because all of the other state in it is about fixed-function stuff which
is
I think if you change the clip depth mode without changing the clip
origin then only the _NEW_VIEWPORT state would be set. Does that mean we
have to add _NEW_VIEWPORT to the state for the gen7_clip_state atom as
well to make sure that upload_clip_state is called?
There is also some state for the f
Hi,
Mathias Fröhlich writes:
> That moved to MESA_META_TRANSFORM due to a review request. As I
> understood the rationale, it's already connected to the
> gl_context::Transform variable by the GL spec, so it belongs into
> transform also for meta operations. Brian, or what was there an other
> r
Brian Paul writes:
> We've always put GL state into the attribute group specified by the GL
> specification. Putting the new clip control state anywhere but in the
> gl_context::Transform group would be inconsistent.
I think Mathias was asking whether it could be put under a different
*meta*
Hi,
I was thinking of taking a look at implementing proper conditional
rendering for i965. Currently it looks like we cheat to implement this
and just stall the GPU to wait for the result before deciding whether to
issue the 3DPRIMITIVE command. I think Gen7+ can support it in hardware
with the MI
MENT. IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS
+ * IN THE SOFTWARE.
+ *
+ * Authors
THE USE OR OTHER DEALINGS
+ * IN THE SOFTWARE.
+ *
+ * Authors:
+ *Neil Roberts
+ */
+
+/** @file brw_conditional_render.c
+ *
+ * Support for conditional rendering based on query objects
+ * (GL_NV_conditional_render, GL_ARB_conditional_render_inverted) on Gen7+.
+ */
+
+#include "m
In order to detect whether the predicate source registers can be used in a
later patch we will need to know the version number for the command parser.
This patch just adds a member to intel_screen and does an ioctl to get the
version.
---
src/mesa/drivers/dri/i965/intel_screen.c | 7 +++
src/m
> On Fri, Nov 07, 2014 at 03:28:01PM +0000, Neil Roberts wrote:
>> Unfortunately these two source registers are not in the whitelist of
>> available registers in the kernel driver so this needs a kernel patch
>> to work. This patch tries to check whether it is possibl
Neil Roberts writes:
> It looks like the PRM for Haswell says that MI_LOAD_REGISTER_MEM is
> converted to no-op for non-privileged buffers. However I can't find any
> mention of this for IvyBridge. Does that mean it's allowed on IvyBridge
> but it won't work on Hasw
Kenneth Graunke writes:
> drm-intel-next must have the new software checker turned on, which
> disallows non-whitelisted register writes (along with libva, so it
> can't really be enabled upstream yet).
For what it's worth, I get the EINVAL error even on the stock Fedora 20
kernel on Haswell (an
---
src/glsl/linker.cpp | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/glsl/linker.cpp b/src/glsl/linker.cpp
index bd2aa3c..41d6a82 100644
--- a/src/glsl/linker.cpp
+++ b/src/glsl/linker.cpp
@@ -2411,7 +2411,7 @@ reserve_explicit_locations(struct gl_shader_program *prog,
For what it's worth, I did a quick grep through the internal and public
shader-db and I couldn't find anything using this.
git grep -P '\b(? writes:
> On Thu, 2014-11-20 at 08:08 +0100, Iago Toral wrote:
>> On Wed, 2014-11-19 at 10:27 -0800, Ian Romanick wrote:
>> > On 11/19/2014 03:47 AM, Iago
When restoring the current state in _mesa_meta_end it was previously trying to
copy the on-going sample count of the current occlusion query into the new
query after restarting it so that the driver will continue adding to the
previous value. This wouldn't work for two reasons. Firstly, the query m
Flex and lex have a special action ‘|’ which means to use the same action as
the next rule. We can use this to reduce a bit of code duplication in the
rules for the various float literal formats.
---
src/glsl/glsl_lexer.ll | 15 +++
1 file changed, 3 insertions(+), 12 deletions(-)
dif
According to the GLSL spec float literals like ‘1f’ shouldn't be allowed
without adding a decimal point or an exponent. Apparently the AMD driver also
disallows this so it seems unlikely that anything would be relying on it.
---
This was discussed here:
http://lists.freedesktop.org/archives/mesa-
The render surface state command for Skylake doesn't have the surface
array spacing bit so it's not possible to select this layout. I think
it was only used in order to make it pick a tightly-packed qpitch
value that doesn't include space for the mipmaps. However this won't
be necessary after the n
Commit 0ac4c272755c7 made it add a header for the send message when
using SIMD4x2 on Skylake because without this it will end up using
SIMD8D. However the patch missed the case when a sampler is being used
to implement constant loads from a buffer surface in a SIMD4x2 vertex
shader.
This fixes 29
On Skylake the qpitch value is uploaded as part of the surface state
so we don't need to add the extra rows that are done for other
generations. However for 3D textures it needs to be aligned to the
tile height and for depth/stencil textures it needs to be a multiple
of 8. Unlike previous generatio
The places that were checking whether 3-source instructions are
supported have now been combined into a small helper function. This
will be used in the next patch to add an additonal restriction.
Based on a patch by Kenneth Graunke.
---
Matt's review for v1 of this patch was conditional based on
From: Kenneth Graunke
Several steppings of Skylake fail when using SIMD16 with 3-source
instructions (such as MAD).
This implements WaDisableSIMD16On3SrcInstr and fixes ~190 Piglit
tests.
Based on a patch by Neil Roberts.
---
src/mesa/drivers/dri/i965/brw_shader.cpp | 6 ++
1 file changed
Ben Widawsky writes:
> This patch actually addresses two potential issues:
> 1. As far as I can tell, drm_intel_gem_bo_alloc_tiled() which is invariably
> called, can potentially change the tiling type. Therefore, we shouldn't be
> checking the requested tiling type, but rather the granted tilin
Looks good to me.
Reviewed-by: Neil Roberts
- Neil
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Ben Widawsky writes:
> diff --git a/src/mesa/drivers/dri/i965/intel_blit.h
> b/src/mesa/drivers/dri/i965/intel_blit.h
> index f563939..531d329 100644
> --- a/src/mesa/drivers/dri/i965/intel_blit.h
> +++ b/src/mesa/drivers/dri/i965/intel_blit.h
> @@ -30,6 +30,9 @@
>
> #include "brw_context.h"
Ben Widawsky writes:
> diff --git a/src/mesa/drivers/dri/i965/intel_blit.h
> b/src/mesa/drivers/dri/i965/intel_blit.h
> index 52dd67c..aff2d58 100644
> --- a/src/mesa/drivers/dri/i965/intel_blit.h
> +++ b/src/mesa/drivers/dri/i965/intel_blit.h
> @@ -78,14 +78,34 @@ void intel_emit_linear_blit(st
Sorry for the delay in replying to this.
Ben Widawsky writes:
>> > +static inline uint32_t
>> > +intel_miptree_blit_height(struct intel_mipmap_tree *mt)
>> > +{
>> > + switch (mt->target) {
>> > + case GL_TEXTURE_CUBE_MAP:
>> > + case GL_TEXTURE_1D_ARRAY:
>> > + case GL_TEXTURE_2D_ARRAY:
Commit cf67ca9ffa9 made the layouting code pick a special layout for
1D images on Skylake. This should not be used for depth and stencil
buffers because these need to be treated as 2D tiled images. However
the patch was missing a check for images with a base format of
GL_STENCIL_INDEX. In practice
It seems a bit strange that this has stopped working for you. If you
specify a mode in the .dir-locals.el file then it's supposed to set the
variable for any files with that mode or any modes inherited from that
mode. The C and C++ modes both inherit from prog-mode, as well as a
bunch of other ones
Ben Widawsky writes:
> Can you do me a favor since I am lazy? Can you send the generated asm
> diff with this patch? I am admittedly rusty on the matter, but I
> thought a mov is just a mov, and only the regioning is effected by the
> retype. If it indeed does what you say, it really should fix
>
Ben Widawsky writes:
> Does this happen to allow concurrent piglit to not die in a fire?
Hrm, I just tried running piglit without -1 on my wip/skylake branch
(without this patch) and it seems to work fine! I don't know what has
fixed it but these are the three patches on that branch:
d2e8cd7 i9
Commit 5a06ee738 added a step to the generator to set up the message
header when generating the VS_OPCODE_PULL_CONSTANT_LOAD_GEN7
instruction. That pseudo opcode is implemented in terms of multiple
actual opcodes, one of which writes to one of the source registers in
order to set up the message hea
Ben Widawsky writes:
>> + void generate_set_simd4x2_header_gen9(vec4_instruction *inst,
>> + struct brw_reg dst);
>
> super bikesheddy, but this function name sounds pretty bad, though I
> understand it's a side-effect of the name of the opcode (which see
Commit 5a06ee738 added a step to the generator to set up the message
header when generating the VS_OPCODE_PULL_CONSTANT_LOAD_GEN7
instruction. That pseudo opcode is implemented in terms of multiple
actual opcodes, one of which writes to one of the source registers in
order to set up the message hea
There were three places in the visitor that had a similar chunk of
code to emit the VS_OPCODE_PULL_CONSTANT_LOAD opcode using a register
for the offset. This patch combines the chunks into a helper function
to reduce the code duplication. It will also be useful in the next
patch to expand what happ
Anuj Phogat writes:
> This will allow Skylake to use _mesa_meta_pbo_GetTexSubImage() for reading
> YF/YS
> tiled surfaces.
>
> V2: Make changes suggested by Neil.
>
> Signed-off-by: Anuj Phogat
> Cc: Neil Roberts
> ---
> src/mesa/drivers/common/meta.h
Ilia Mirkin writes:
> That seems awkward... did you mean 1U? FWIW mesa's not at all careful
> about that...
Or maybe even UINT64_C(1). 1l would still be 32-bit on 32-bit
architectures. I guess this is more of a problem for subsequent flags
that go over 32-bit.
- Neil
___
On Gen9+ there needs to be a header when sampling using SIMD4x2. The
header is set up by copying from the g0 register. Commit 07c571a39f
tried to fix this mov instruction to always use an exec size of 8
because previously it was incorrectly using 4. It did this by casting
the type of the destinatio
If a send message is emitted with a message length that is less than
required for the message then the remaining parameters default to
zero. We can take advantage of this to save a register when a shader
passes constant zeroes as the final coordinates to the sample
function.
I think this might be
Matt Turner writes:
>> + foreach_block_and_inst(block, fs_inst, inst, cfg) {
>> + if ((inst->opcode == SHADER_OPCODE_TEX ||
>> + inst->opcode == SHADER_OPCODE_TXF) &&
>> + !inst->shadow_compare) {
>> + fs_inst *load_payload = (fs_inst *) inst->prev;
>> +
>> +
Kenneth Graunke writes:
> I like this idea!
>
> We definitely need to skip this optimization on Gen4, since the Gen4/G45
> sampler infers the texturing opcode based on the message length. But
> for Gen5+, it should be no problem.
Ah ok, yes, I will add this.
> Matt mentioned that we have to em
Looks good to me. Sorry about breaking it.
Reviewed-by: Neil Roberts
- Neil
Rob Herring writes:
> Commit 5fd848f6c9ee ("program: Use _mesa_geometric_samples to calculate
> gl_NumSamples") broken Android builds. Add the missing include path "main"
> to framebu
Looks good to me. Interestingly we have a test for it in Piglit which
gets run with samples=0 and it is currently passing so presumably it is
broken.
Reviewed-by: Neil Roberts
- Neil
Ilia Mirkin writes:
> From ARB_sample_shading:
>
> "gl_NumSamples is the total number of
I made a pathological test case (attached) which repeatedly renders into
an MSAA FBO and then blits it to the screen and measures the framerate.
It checks it with a range of different sample counts. The rendering is
done either by rendering two triangles to fill the framebuffer or by
calling glClea
Iago Toral writes:
> I don't know much about this, but using shader_samples_identical
> should only give a benefit if we actually get identical samples,
> otherwise it means more work, right? I noticed that the test renders a
> quad with random colors for each vertex that will be interpolated
> a
According to the Vulkan 1.0 spec section 9.4:
“When an application attempts to create many pipelines in a single
command, it is possible that some subset may fail creation. In that
case, the corresponding entries in the pPipelines output array will
be filled with VK_NULL_HANDLE values. If any p
There are currently a bunch of formats that behave strangely when
sampling the cleared color from the MCS buffer on SKL. They seem to
mostly be formats that don't have an alpha component, although it's
not all of them, and we haven't yet found anything in the specs which
would explain this. For now
Chad Versace writes:
> Neil, do you have a bug open for this?
What kind of bug do you mean? I don't think it would make sense to open
a Freedesktop bug because it doesn't cause any problems as fast clears
aren't enabled at all yet for SKL.
> Reviewed-by: Chad Versace
Thanks for the review.
R
According to the GLES3 spec, blitting between multisample FBOs with
different internal formats should not be allowed. The
compatible_resolve_formats function implements this check. Previously
it had a shortcut where if the Mesa formats of the two renderbuffers
were the same then it would assume the
Previously fast clear was disallowed on Gen9 for MSRTs with the claim
that some formats don't work but we didn't understand why. On further
investigation it seems the formats that don't work are the ones where
the render surface format is being overriden to a different format
than the one used for
Since Gen8 this is allowed as a rendering target so we don't need to
override it to B8G8R8A8. This is helpful on Gen9+ where using this
override causes fast clears not to work.
---
src/mesa/drivers/dri/i965/brw_surface_formats.c | 9 +
1 file changed, 5 insertions(+), 4 deletions(-)
diff
The tiled memcpy doesn't work for copying from RGBX to RGBA because it
doesn't override the alpha component to 1.0. Commit 2cebaac479d4 added
a check to disable it for RGBX formats by looking at the TexFormat.
However a lot of the rest of the code base is written with the
assumption that an RGBA te
The RGBX surface formats aren't renderable so we internally remap them
to RGBA when rendering. They are retained as RGBX when used as
textures. However since the previous patch fast clears are disabled
for surfaces that use a different format for rendering than for
texturing. To avoid this situatio
to leave tackling that for
> a separate series.
You might want to remove this paragraph now that it's no longer true.
The patch looks good to me.
Reviewed-by: Neil Roberts
Just to note, I posted a patch which changes the check to allow fast
clears for certain MSRT formats. However it still
Jason Ekstrand writes:
> On Nov 18, 2015 6:38 PM, "Ian Romanick" wrote:
>>
>> From: Ian Romanick
>>
>> v2: Handle immediate value for MCS smarter. Rebase on changes to
>> nir_texop_sampels_identical (missing second parameter). Suggested by
>> Jason. This still doesn't handle the 16x MSAA cas
Ian Romanick writes:
> Am I correct that nothing special is needed in the vec4 backend? It
> seems like mcs should know the register size, and the CMP with 0
> should just do the right thing.
I think you probably will have to do something for the vec4 backend.
Currently it generates an instructi
Jason Ekstrand writes:
> Something else that came out of that conversation is that, for 2x
> MSAA, we may get bogus data in all but the bottom 4 bits. In other
> words, just blindly checking for zero is probably a bad idea. It'll
> work because the extension spec lets us return false negatives,
Ben Widawsky writes:
> I really don't know the corner cases well enough, but concept seems
> good to me. In particular, I assume this is now going to return false
> for more cases than previously - and that's okay, I guess?
In practice I don't think it will disable any extra formats because the
Ben Widawsky writes:
>> + /* The RGBX formats are not renderable. Normally these get mapped
>> +* internally to RGBA formats when rendering. However on Gen9+ when this
>> +* internal override is used fast clears don't work so they are disabled
>> in
>> +* brw_meta_fast_clear. To av
Ben Widawsky writes:
>> + if (brw->gen >= 9 &&
>> + brw_format_for_mesa_format(irb->mt->format) !=
>> + brw->render_target_format[irb->mt->format])
>
> Could you just do
> !brw->format_supported_as_render_target[irb->mt->format]?
Hrm, yes, you're right, that would be much
> Ben Widawsky writes:
>
>>> + if (brw->gen >= 9 &&
>>> + brw_format_for_mesa_format(irb->mt->format) !=
>>> + brw->render_target_format[irb->mt->format])
>>
>> Could you just do
>> !brw->for
I've pushed this patch to master but I think it would be a good
candidate to go on the 11.1 branch as well. Do I have to do something to
make that happen?
- Neil
Neil Roberts writes:
> It looks like the sampler hardware doesn't take into account the
> surface format when sa
Hi,
Has this situation changed at all? It's probably quite important to get
this working because we have to disable fast clears for X-tiled buffers
on SKL which effectively means we currently can't do it for window
system buffers.
Regards,
- Neil
Chris Wilson writes:
> On Mon, Apr 13, 2015 at
If GL_FRAMEBUFFER_SRGB is enabled when writing to an SRGB-capable
framebuffer then the color will be converted from linear to SRGB
before being written. There is no chance for the hardware to do this
itself because it can't modify the clear color that is programmed in
the surface state so it seems
Adds MESA_META_FRAMEBUFFER_SRGB to the meta save state so that
GL_FRAMEBUFFER_SRGB will be disabled when performing the fast clear.
That way the render surface state will be programmed with the linear
equivalent format during the clear. This is important for Gen9 because
the SRGB formats are not ma
When GL_FRAMEBUFFER_SRGB is enabled any single-sampled renderbuffers
are resolved in intel_update_state because the hardware can't cope
with fast clears on SRGB buffers. In that case it's pointless to do a
fast clear because it will just be immediately resolved.
---
src/mesa/drivers/dri/i965/brw_m
SRGB buffers are not marked as losslessly compressible so previously
they would not be used for fast clears. However in practice the
hardware will never actually see that we are using SRGB buffers for
fast clears if we use the linear equivalent format when clearing and
make sure to resolve the buff
For single-sampled textures the MCS buffer is only used to implement
fast clears. However the surface always needs to be resolved before
being used as a texture anyway so the the MCS buffer doesn't actually
achieve anything. This is important for Gen9 because in that case SRGB
surfaces are not supp
Currently fast clears are disabled on SKL with SRGB buffers because
they are not marked as losslessly compressible in the formats table.
This is less than ideal because by default the window system buffers
are created as SRGB so in practice it means an application is unlikely
to end up using fast c
SKL can't cope with the CCS buffer for SRGB buffers. Normally the
hardware won't see the SRGB formats because when GL_FRAMEBUFFER_SRGB
is disabled these get mapped to their linear equivalents. In order to
avoid relying on the CCS buffer when it is enabled this patch now
makes it flush the renderbuf
> On Thu, Nov 26, 2015 at 11:18:34AM +0200, Pohjolainen, Topi wrote:
>> On Wed, Nov 25, 2015 at 11:01:18AM -0800, Ben Widawsky wrote:
>> > On Wed, Nov 25, 2015 at 06:36:36PM +0100, Neil Roberts wrote:
>> > > For single-sampled textures the MCS buffer is only used t
When converting 0.0 it would be nice if it didn't do any arithmetic.
---
src/util/format_srgb.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/util/format_srgb.h b/src/util/format_srgb.h
index 4a8d73f..34b50af 100644
--- a/src/util/format_srgb.h
+++ b/src/util/format_srgb.
"Pohjolainen, Topi" writes:
>> + /* Handle linear→SRGB conversion */
>> + if (brw->ctx.Color.sRGBEnabled &&
>> + _mesa_get_srgb_format_linear(mt->format) != mt->format) {
>
> Patch five disables fast clear for single-sampled if
> brw->ctx.Color.sRGBEnabled is set. How about something li
Matt Turner writes:
> # Written in the form (, ) where is an expression
> # and is either an expression or a value. An expression is
> # defined as a tuple of the form (, , , , )
> @@ -94,6 +97,8 @@ optimizations = [
> (('inot', ('ige', a, b)), ('ilt', a, b)),
> (('inot', ('ieq', a,
If EGL_KHR_surfaceless_context is used then glViewport can be called
with NULL for the draw and read surfaces. This was previously causing
a crash because the i965 driver tries to use this point to invalidate
the surfaces and it was derferencing the NULL pointer.
Bugzilla: https://bugs.freedesktop
Emil Velikov writes:
> Worth throwing in 11.0 as well ?
Yeah, that would probably be sensible.
>> if (_mesa_is_winsys_fbo(ctx->DrawBuffer)) {
>> - dri2InvalidateDrawable(driContext->driDrawablePriv);
>> - dri2InvalidateDrawable(driContext->driReadablePriv);
>> + if (driContex
Previously if the visual didn't have an alpha channel then it would
pick a format that is not sRGB-capable. I don't think there's any
reason not to always have an sRGB-capable visual. Since 28090b30 there
are now visuals advertised without an alpha channel which means that
games that don't request
brw_init_surface_formats overrides the render format for RGBX formats
which aren't supported for rendering so that they internally use RGBA
instead. However, B8G8R8X8_SRGB was missing so it wasn't marked as a
renderable format. This patch just adds it.
Cc: "11.0 11.1"
Cc: Ilia Mirkin
---
src/me
This will be used in a subsequent patch as the format for RGB visuals.
Cc: "11.0 11.1"
Cc: Ilia Mirkin
Suggested-by: Ilia Mirkin
---
src/mesa/drivers/dri/i965/brw_surface_formats.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/src/mesa/drivers/dri/i965/brw_surface_formats.c
b/src/mesa/d
301 - 400 of 506 matches
Mail list logo
