In Skylake the order of the arguments for sample messages with the LD
type are u, v, lod, r whereas previously they were u, lod, v, r. This
fixes 82 Piglit tests using texelFetch.
---
I have a feeling this probably isn't the right way to do this patch so
maybe someone who knows the compiler better
15, Emil Velikov wrote:
>> On 4 March 2015 at 17:22, Neil Roberts wrote:
>>> This reverts commit 546aba143d13ba3f993ead4cc30b2404abfc0202.
>>>
>>> I think the changes to the calls to glBlitFramebuffer from this patch
>>> are no different to what it was doing
In Skylake the order of the arguments for sample messages with the LD
type are u, v, lod, r whereas previously they were u, lod, v, r.
This fixes 144 Piglit tests including ones that directly use
texelFetch and also some using the meta stencil blit path which
appears to use texelFetch in its shade
Ben Widawsky writes:
> On Fri, Feb 20, 2015 at 10:31:08PM +0000, Neil Roberts wrote:
>> The render surface state command for Skylake doesn't have the surface
>> array spacing bit so I don't think it's possible to select this
>> layout. This avoids a kerne
Ben Widawsky writes:
> This patch will use a new calculation to determine if a surface can be blitted
> from or to. Previously, the "total_height" member was used. Total_height in
> the
> case of 2d, 3d, and cube map arrays is the height of each slice/layer/face.
> Since the GL map APIS only eve
It seems a bit weird to modify the the is_power_of_two functions in
format_parser.py, was that intentional? It doesn't look like those
functions are actually used anywhere so maybe we could just remove them,
although it would probably make sense to do that in a separate patch.
Regards,
- Neil
Anu
I tested this on my BXT by running the glsl-fs-color-matrix test (which
ends up using MAD in SIMD16) and it worked fine.
Tested-by: Neil Roberts
Reviewed-by: Neil Roberts
- Neil
Ben Widawsky writes:
> This is easily accomplished by moving simd16 3src to GEN9_FEATURES.
>
> Signed-of
Previously it could end up using the “SKL early” device on BXT
depending on the revision number. This would probably break things
because for example has_llc would be wrong.
---
src/mesa/drivers/dri/i965/brw_device_info.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/src/m
Looks good to me.
Reviewed-by: Neil Roberts
- Neil
Anuj Phogat writes:
> Signed-off-by: Anuj Phogat
> Cc: Neil Roberts
> ---
> src/mesa/main/format_parser.py | 7 ---
> 1 file changed, 7 deletions(-)
>
> diff --git a/src/mesa/main/format_parser.py b/src/mesa/
ying about too much. But of course a bug is a bug so it would be
nice to land them at some point.
http://patchwork.freedesktop.org/patch/54324/
http://patchwork.freedesktop.org/patch/54325/
Regards,
- Neil
Emil Velikov writes:
> Hello Neil,
>
> On 10 July 2015 at 18:04, Neil Roberts
Adds nir_src_is_dynamically_uniform which returns true if the source
is known to be dynamically uniform. This will be used in a later patch
to add a workaround for cases that only work with dynamically uniform
sources. Note that the function is not definitive, it can return false
negatives (but not
If a non-const sample number is given to interpolateAtSample it will
now generate an indirect send message with the sample ID similar to
how non-const sampler array indexing works. Previously non-const
values were ignored and instead it ended up using a constant 0 value.
The generator will try to
of
> early ones (a hopefully irrelevant improvement IMO).
>
> Cc: Jason Ekstrand
> Cc: Neil Roberts
> Signed-off-by: Ben Widawsky
> ---
> src/mesa/drivers/dri/i965/brw_device_info.c | 15 +++
> 1 file changed, 7 insertions(+), 8 deletions(-)
>
> diff --
t anyway for consistency.
If you wanted to optimise it a bit more you could move the
if(src_bits==dst_bits) to above the first if statement because I think
it would be tricky the for the compiler to optimise that away.
Either way,
Reviewed-by: Neil Roberts
Regards,
- Neil
_
Since 4d7e0fa8c731776 this file is generated by the configure script.
---
src/gallium/targets/opencl/.gitignore | 1 +
1 file changed, 1 insertion(+)
create mode 100644 src/gallium/targets/opencl/.gitignore
diff --git a/src/gallium/targets/opencl/.gitignore
b/src/gallium/targets/opencl/.gitigno
Are you sure this patch is necessary? The documentation for the multiply
instruction on BDW+ says:
SourceType :*D
DestinationType : *D
Project : EXCLUDE(CHV)
This to me implies that it should work on BXT because it doesn't say
EXCLUDE(BXT).
I made a little test case
ed.
Doing a follow-on patch is fine by me. I'm not sure what you mean by the
logic being used pre-HSW, but I guess I'll see when you post the patch
:)
> Neil, you said "if we go with this patch" - I haven't heard any
> opposition, do you have any?
No, it seems
cumentation and simulator implies this shouldn't work
I'm happy to leave this patch and I'm not suggesting we do anything now.
Regards,
- Neil
1.
https://github.com/bpeel/piglit/blob/test-integer-multiply-uniform/tests/general/mult32.c
Francisco Jerez writes:
> Neil Roberts wri
Ben Widawsky writes:
> Also, I just noticed:
> "It is INVALID to store both the VertexID and InstanceID in the same
> element/component location within the VUE."
>
> Aren't we potentially doing that today (and still with your patch)?
Perhaps this means you can't store the VID and the IID in the
Ilia Mirkin writes:
> @@ -2757,6 +2764,11 @@ builtin_builder::add_image_functions(bool glsl)
>"__intrinsic_image_size",
>&builtin_builder::_image_size_prototype, 1,
>flags | IMAGE_FUNCTION_SUPPORTS_FLOAT_DATA_TYPE);
> +
> +
Good catch and it seems like a nice way to fix it.
Reviewed-by: Neil Roberts
I wonder if it might be worth avoiding copying the padding and pack the
rows more tightly in the temporary buffer. Ie, we would allocate a
buffer of align(width*cpp)*height*depth and copy the rows in one at a
time
The clear texture extension is used to clear a texture to a given value
without having to provide a buffer for the whole texture and without having to
create an FBO. This patch provides a generic implementation that works with
any driver. There are two approaches, the first being in meta.c which tr
This adds a test for glClearTexSubImage when clearing a sub-region of
a cube map texture. Each face of the cube map is cleared to a separate
colour and then one pixel of each face is rendered using points. The
colours are then probed to check whether the clear worked. This is
important to test beca
This adds a test for glClearTexSubImage when clearing a sub-region of
a depth-stencil texture. A 2x2 texture is created and then two pixels
of it are cleared using different values. The texture is then read
back using glGetTexImage and compared with the expected values.
This is important to test b
This adds a test for glClearTexSubImage when clearing a sub-region of
a 3D texture. Two sub-regions are cleared, one using a NULL data
parameter and one providing a colour. Both regions have a depth
greater than 1. All of the images of the texture are then rendered to
the window and probed for the
Hi,
This should fix the problem with depth-stencil textures mentioned in
the commit message for my GL_ARB_clear_texture patch here:
http://lists.freedesktop.org/archives/mesa-dev/2014-June/060739.html
- Neil
--- >8 --- (use git am --scissors to automatically chop here)
intel_mi
This adds a test for updating a sub-region of a texture created with
the GL_EXT_packed_depth_stencil extension. Currently this seems to
trigger a bug on the i965 driver.
---
tests/all.py | 1 +
.../ext_packed_depth_stencil/CMakeLists.gl.txt | 1 +
test
When a multisampled texture is used for sampling the fast clear color value
needs to be programmed into the surface state. This was being left as all
zeroes so if the surface was cleared to a value other than black then it
wouldn't work properly. This doesn't matter for single-sample textures becau
(I was trying to be too clever with git-sendmail and I accidentally
sent this to the wrong list… sorry!)
Jason wrote:
> Kristian and I were looking at this today, and there seems to be a
> substantial race in the way that we are doing texture locking.
Yes, it does look like this is a problem. I
Thanks for the review.
I'm working on incorporating the changes into a v2 patch series. However
I'm a bit stuck with what to do about enabling the extension assuming
there is no Gallium implementation for now. I couldn't find a convenient
place to enable the extension for all DRI-based drivers wit
The comment for _mesa_is_type_integer is confusing because it says that it
returns whether the type is an “integer (non-normalized)” format. I don't
think it makes sense to say whether a type is normalized or not because it
depends on what format it is used with. For example, GL_RGBA+GL_UNSIGNED_BY
Brian Paul writes:
> Reviewed-by: Brian Paul
>
> Do you need someone to commit/push this?
Thanks for the review. I do have commit access for Mesa so I've just
pushed it.
As an aside, I don't have commit access for Piglit and I haven't been
able to find someone who can grant me access. If you a
This adds the driver entry point for glClearTexSubImage and fills in the
_mesa_ClearTexImage and _mesa_ClearTexSubImage functions that call it.
---
src/mesa/main/dd.h | 14 +++
src/mesa/main/teximage.c | 241 ++-
src/mesa/main/teximage.h | 12 +++
In texture_error_check() there was a snippet of code to check whether the
given format and internal format are basically compatible. This has been split
out into its own static helper function so that it can be used by an
implementation of glClearTexImage too.
---
src/mesa/main/teximage.c | 63 +++
Here is a second attempt at implementing the GL_ARB_clear_texture
extension. I've split up the patch into serveral smaller patches. They
are based on top of the first patch in Ilia's series which is
available here:
https://github.com/imirkin/mesa/commit/9c2467020a8a3895a1debbad06561f37
I think I'
This adds a function called _mesa_init_driver_extensions that is called by all
DRI-based drivers. The intention is that any extensions that are implemented
directly by _mesa_init_driver_functions without any driver-specific
entrypoints will be enabled here.
---
src/mesa/drivers/common/driverfuncs.
Adds an implmentation of the ClearTexSubImage driver entry point that just
maps the texture and writes the values in. This should work as a reliable
fallback on any driver.
---
src/mesa/drivers/common/driverfuncs.c | 2 +
src/mesa/main/texstore.c | 70
Adds an implementation of the ClearTexSubImage driver entry point that tries
to set up an FBO to render to the texture and then calls glClear with a
scissor to perform the actual clear. If an FBO can't be created for the
texture then it will fall back to using _mesa_store_ClearTexSubImage.
---
src
Ilia Mirkin writes:
>> + if (ctx->Version >= 30 || ctx->Extensions.EXT_texture_integer) {
>
> Just ctx->Extensions.EXT_texture_integer should be enough here, no?
I'm reluctant to change this because every other place in the code that
checks for integer textures does it in the same way. Perhaps
Ilia Mirkin writes:
> Will it? What about the MS case? I thought that for generic you had to
> do a shader-based approach.
Ah yes, you're right the commit message is nonsense. I guess I should
also avoid enabling the extension at all until the next patch.
> While I'm sure we all love the
>
> wh
Previously the blorp blitter would only be used if the format is identical or
there is only a difference between whether there is an alpha component or not.
This patch makes it also allow the blorp blitter if the only difference is the
ordering of the RGB components (ie, RGB or BGR).
This is parti
Matt Turner writes:
> We typically write
>
> Bugzilla: https:///
>
> Reviewed-by: Matt Turner
>
> Do you have commit access?
Thanks for the review. I do have commit access so I've pushed the patch
with the suggested change to the commit message.
I've also started to try and look at why tha
Hi,
I've been looking into this bug a bit more. I don't think disabling the
blorp path on Sandybridge is the right thing to do. The only notable
difference between the blorp code path and the meta code path seems to
be that the blorp code forces the use of non-normalized coordinates
whereas the me
> FWIW, I relaxed the format restrictions in
> brw_blorp_copytexsubimage, so it can handle general format
> conversions as well (i.e. RGBA_FLOAT16 -> RGBA_UNORM). There's
> no reason we couldn't do that for BlitFramebuffer as well, I just
> forgot to do it (and then we decided to make it a newb
Jason Ekstrand writes:
>> + texImages[0] = _mesa_select_tex_image(ctx, texObj, texObj->Target,
>> level);
>>
>
> Do you want this inside an else block?
I think it's quite a common idiom in Mesa to handle the special cases as
a series of if-statements with a return upfront before handling the
n
Ian Romanick writes:
> Are there potentially cases where the first clear_tex_image could
> succeed but the second fail? If so, then this is no good. If a GL call
> generates an error (other than GL_NO_MEMORY), it is supposed to be as
> though nothing happened.
Urgh, yes, you're right because f
Jason Ekstrand writes:
>> +static void
>> +clear_image_to_zero(GLubyte *dstMap, GLint dstRowStride,
>> +GLsizei width, GLsizei height,
>> +GLsizei clearValueSize)
>> +{
>> + while (height-- > 0) {
>> + memset(dstMap, 0, clearValueSize * width);
>> +
Ilia Mirkin writes:
> Not entirely sure how to interpret what the spec says, but something
> to potentially consider is MESA_ycbcr_texture (supported by swrast).
> RGBA 0 (black) != 0 in ycbcr... all 0's there are a green color.
The spec for the extension says:
“If is NULL, then the pointer is
Ian Romanick writes:
> Every driver in Mesa supports GL_EXT_framebuffer_object and
> GL_EXT_framebuffer_blit. […]
>
> So, I don't think this check adds any value.
Ok.
>> + /* This probably won't work with images that have a border */
>> + if (texImage->Border != 0)
>> + return false;
>
When attaching a texture to a framebuffer it was previously using the size of
the texture minus the border when determining the renderbuffer size. However
the size of the image buffer includes the border so when used with the swrast
driver it would end up calculating the wrong stride and it would r
Here is version 3 of the patches to implement GL_ARB_clear_texture. The main
changes are:
• The extension is now only enabled for the i965 driver. I've removed the
patch to add a place to enable extensions for all DRI drivers.
• It now checks for potential errors that would occur when clearing
This adds the driver entry point for glClearTexSubImage and fills in the
_mesa_ClearTexImage and _mesa_ClearTexSubImage functions that call it.
v2: Don't clear some of the images if only one of them makes an error
Reviewed-by: Jason Ekstrand
---
src/mesa/main/dd.h | 14 +++
src/mesa/main
In texture_error_check() there was a snippet of code to check whether the
given format and internal format are basically compatible. This has been split
out into its own static helper function so that it can be used by an
implementation of glClearTexImage too.
---
src/mesa/main/teximage.c | 59 +++
Adds an implmentation of the ClearTexSubImage driver entry point that just
maps the texture and writes the values in. The extension is not yet enabled by
default because it doesn't work with multisample textures as they don't have a
simple linear layout.
Reviewed-by: Jason Ekstrand
---
src/mesa/
From: Ilia Mirkin
Signed-off-by: Ilia Mirkin
Reviewed-by: Neil Roberts
---
src/mapi/glapi/gen/ARB_clear_texture.xml | 34
src/mapi/glapi/gen/gl_API.xml| 6 +-
src/mesa/main/extensions.c | 1 +
src/mesa/main/mtypes.h
Adds an implementation of the ClearTexSubImage driver entry point that tries
to set up an FBO to render to the texture and then calls glClear with a
scissor to perform the actual clear. If an FBO can't be created for the
texture then it will fall back to using _mesa_store_ClearTexSubImage.
When us
Ilia Mirkin writes:
> I believe what this is saying is akin to "Danger! There is a hole from
> 145 to 146". Since ARB_clear_texture is 145, the hole is now just 146
> (ARB_enhanced_layouts)... Whereas your comments indicate the numbers
> of the actually-listed extensions.
>
> Note that I don't re
"Pohjolainen, Topi" writes:
> Oh, I didn't realize that. Should we fix and put this into
> _mesa_meta_begin/_mesa_meta_end instead?
Yes, perhaps that would be a good idea. I will try writing a separate
patch for that.
Thinking about it a bit more I also realised I'm not handling sRGB
textures c
Here is version 3 of the glClearTexImage implementation. I figured out
I could avoid the whole issue of preserving the glClearColor state by
using glClearBuffer instead of glClear. I think the patch is a lot
neater this way.
I also fixed using sRGB textures and explicitly disabled dithering.
- Ne
The Meta implementation of glClearTexSubImage is going to want to ensure that
dithering is disabled so that it can get a consistent color across the whole
texture when clearing. This adds a state flag to easily save it and set it to
the default value when performing meta operations.
---
src/mesa/d
"Pohjolainen, Topi" writes:
> Here in this function you use glClearBuffer*() and later on in
> cleartexsubimage_depth_stencil() you use _mesa_ClearBuffer*() - I
> would switch to the latter here also.
Ah, whoops, yes, sorry about that. I'll fix it up in the Git branch.
Thanks again for the revi
"Pohjolainen, Topi" writes:
> All the other state flags considered in _mesa_meta_begin() are
> explicitly set as disabled. And having noticed that you
> unconditionally disable dithering also in cleartexsubimage_using_fbo()
> I'm wondering if I'm missing something.
My understanding is that _mesa
Enables BPTC texture compression on the software rasterizer.
---
src/mesa/main/extensions.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/src/mesa/main/extensions.c b/src/mesa/main/extensions.c
index 2db27f4..154c1cd 100644
--- a/src/mesa/main/extensions.c
+++ b/src/mesa/main/extensions.c
@@
Adds functions to fetch from any of the four BPTC-compressed formats.
---
src/mesa/Makefile.sources| 1 +
src/mesa/main/texcompress.c | 6 +
src/mesa/main/texcompress_bptc.c | 958 +++
src/mesa/main/texcompress_bptc.h | 34 ++
4 files changed,
Here's a first attempt at a patch series to implement BPTC texture
compression in the i965 driver on Gen>=7.
Getting it to work on the hardware is pretty trivial as it's just a
case of adding some new Mesa format enums and then plugging them
together with the right Intel surface type. However GL r
Enables the BPTC extension on Gen>=7 and adds the necessary format mappings to
get the right surface type value.
---
src/mesa/drivers/dri/i965/brw_surface_formats.c | 5 +
src/mesa/drivers/dri/i965/intel_extensions.c| 2 ++
2 files changed, 7 insertions(+)
diff --git a/src/mesa/drivers/dr
This adds a boolean in the gl_extensions struct for
GL_ARB_texture_compression_bptc as well as an entry in extension_table.
---
src/mesa/main/extensions.c | 1 +
src/mesa/main/mtypes.h | 1 +
2 files changed, 2 insertions(+)
diff --git a/src/mesa/main/extensions.c b/src/mesa/main/extensions.c
This adds the following four Mesa image format enums which correspond to the
four BPTC compressed texture formats:
MESA_FORMAT_BPTC_RGBA_UNORM
MESA_FORMAT_BPTC_SRGB_ALPHA_UNORM
MESA_FORMAT_BPTC_RGB_SIGNED_FLOAT
MESA_FORMAT_BPTC_RGB_UNSIGNED_FLOAT
It also updates the format information functio
This adds compressors for all four of the BPTC compressed-texture formats. For
the RGB and SRGB normalized BPTC textures it works by first compressing each
4x4 block using the existing DXT3 compressor and then converting it to a BPTC
block. The BPTC block loses one bit of information on the green c
> On 07/22/2014 12:09 PM, Neil Roberts wrote:
>> + * The spec for GL_ARB_texture_compression_bptc doesn't mention whether it
>> + * should be included in GL_COMPRESSED_TEXTURE_FORMATS.
Ian Romanick writes:
> What do NVIDIA and AMD do? We should mimic that.
I don'
Ian Romanick writes:
> Is that NVIDIA's off-line compression tool, or is that the compressor
> in the driver?
I was talking about the offline compressor. I don't know what NVidia's
online compressor is like. Yes, perhaps if we can get a quick compressor
with reasonable results then it starts to
Matt Turner writes:
> I was thinking one of the cool things we might be able to do a ETC2 ->
> BC7 transcode on platforms without ETC2 hardware decompression. We
> won't be able to do that without a good compressor.
That sounds like a fun project. It would be a shame to have to
completely decomp
Ilia Mirkin writes:
> Just a thought -- if online compression is highly unexpected, perhaps
> it'd be reasonably to make a *horrid* compressor that doesn't rely on
> any external libraries? I don't know how complex the BPTC format is,
> but I suspect it may be possible to do a simple conversion t
Hi,
I had a quick look at using libsquish and FasTC.
I didn't manage to build the libsquish repo¹ that Matt Turner pointed to
before giving up. It looks like the SSE version of the compressor is
using some MSVC-specific intrinsics which don't build with GCC. It seems
to be using members of __m128
Is this patch necessary? I think the read buffer is part of the
framebuffer state so any meta function that binds its own framebuffer
won't need to save the read buffer, right? This is the case for
_mesa_meta_CopyImageSubData_uncompressed which binds both a read and
write FBO so I think it shouldn'
Jason Ekstrand writes:
> +bool
> +_mesa_meta_CopyImageSubData_uncompressed(struct gl_context *ctx,
> + struct gl_texture_image
> *src_tex_image,
> + int src_x, int src_y, int src_z,
> +
There is one line that is 116 characters long (!) but apart from that:
Reviewed-by: Neil Roberts
Regards,
- Neil
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Looks good to me.
Reviewed-by: Neil Roberts
Regards,
- Neil
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Jason Ekstrand writes:
> This, together with the meta path, provides a almost-complete
> implemetation of ARB_copy_image. The only case that won't work is if
> one of the textures is compressed and has a pitch greater than
> INT16_MAX. I think that's good enough to justify turning on the
> extens
Oh no, I meant to send this to the wayland-devel list. git send-email is
hard. Sorry about that!
- Neil
-
Intel Corporation (UK) Limited
Registered No. 1134945 (England)
Registered Office: Pipers Way, Swindon SN3 1RJ
VAT No: 860 2
Here is another version of the patch which brings back the blocking
when there are no buffers available to cope with the situation where
the compositor isn't immediately releasing buffers. Maybe we could
leave the decision about whether to increase the buffer count to 4 as
a separate patch.
Sorry
Hi,
I made this patch a while ago while adding support for eglSwapInterval
to the Wayland platform. The swap_interval member confused me for a
little while before I realised that it's not used anywhere. I think it
would be good to get rid of it.
Regards,
- Neil
--- >8 --- (use gi
It looks like this bit of code is trying to disable the prime capability if
the driver doesn't support createImageFromFds. However the logic looks a bit
broken and what it would actually do is disable all other capabilities apart
from prime. This patch fixes it to actually disable prime.
---
src/e
In eglCreateContext there is a check for whether the config parameter is zero
and in this case it will avoid reporting an error if the
EGL_KHR_surfacless_context extension is supported. However there is nothing in
that extension which says you can create a context without a config and Mesa
breaks i
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
/null
+++ b/docs/specs/MESA_configless_context.spec
@@ -0,0 +1,120 @@
+Name
+
+MESA_configless_context
+
+Name Strings
+
+EGL_MESA_configless_context
+
+Contact
+
+Neil Roberts
+
+Status
+
+Proposal
+
+Version
+
+Version 1, February 28, 2014
+
+Number
+
+EGL Extension #not
Here is a series of patches to add an extension which makes it
possible to create an EGL context without specifying a config. A
context created in this way can be bound with any surface using the
same EGLDisplay rather than being restricted to those using the same
config. The main use case is that
Part of the gl_renderer_setup function only deals with checking EGL
extensions and doesn't need to have a current context. This patch
moves these checks so that they are done during gl_renderer_create
instead of waiting until we have an output. We will need this in a
later patch because some of the
The gbm-format configuration option can now be specified per-output as
well as in the core config section. If it is not specified it will
default to the format specified in the core section. The
EGL_MESA_configless_context extension is required for this to work. If
this extension is available it wi
In GLES 3 it is not possible to select rendering to the front buffer and
instead selecting GL_BACK has the magic interpretation that it is either the
front buffer on single-buffered configs or the back buffer on double-buffered.
GLES 1 and 2 have no way of selecting the draw buffer at all. In that
Under GLES 3 it is not valid to pass GL_FRONT to glDrawBuffers. Instead,
GL_BACK has a magic interpretation which means it will render to the front
buffer on single-buffered contexts and the back buffer on double-buffered. We
were incorrectly setting the initial value to GL_FRONT for single-buffere
Kristian Høgsberg writes:
> Thanks Neil, series applied to mesa and weston.
Great, thanks!
I've reposted the piglit patch to the piglit list in case someone wants
to review it there.
Regards,
- Neil
___
mesa-dev mailing list
mesa-dev@lists.freedeskto
When submitting the vertex buffers the i965 driver will try to recognise when
multiple attributes are using the same buffer so that it can submit a single
relocation for it and set a different offset in the attribute. Previously
however if the application happens to have the attributes in a struct
Ok, I've written a somewhat contrived test case here:
https://github.com/bpeel/glthing/tree/time-attribs
(Make sure to use the time-attribs branch)
The example draws a 1000 single-pixel points each with a separate draw
call. Each call uses a separate but identical VAO so that the driver
will be
Neil wrote:
> It might be worth making a simpler hard-coded implementation of
> quicksort because calling qsort is probably not very sensible for
> such a small array and the function call overhead for each
> comparison is probably quite a bit.
Ok, here is a v2 of the patch which has a simple cus
If we're looking for something to drop in to Mesa to avoid a dependency
maybe we could look at simpler hashing algorithms too. For the shader
cache presumably we don't care about the hash being cryptographically
secure, just that it is unlikely to *accidentally* make a hash
collision. I think it wo
There is an existing function to attempt to upload texture data from a PBO via
the blit pipeline called try_pbo_upload. However it was only used for the
glTexImage* functions. This patches renames it to intel_try_pbo_upload and
adds parameters to specify the x/y offsets and size and makes intelTexS
This should just be a simple case of adding the skip values to the src offset
so we can trivially implement it.
---
src/mesa/drivers/dri/i965/intel_tex_image.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/src/mesa/drivers/dri/i965/intel_tex_image.c
b/src/mesa/drivers/
Here are some patches to make the i965 driver use the blit pipeline
for sub-texture updates and also for 3D textures and array textures
(including cube map arrays) when using PBOs. I've also posted some
patches to update the texsubimage test in Piglit to make sure these
codepaths are actually teste
intel_try_pbo_upload now iterates over each slice of the uploaded data and
and does a separate blit for each image. This copies in some fiddly details
store_texsubimage in order to handle the image stride correctly for 1D array
textures.
---
src/mesa/drivers/dri/i965/intel_tex.h | 4 +-
101 - 200 of 506 matches
Mail list logo
