This is all leftover from the i965 split.
---
src/mesa/drivers/dri/i915/intel_context.c | 2 --
src/mesa/drivers/dri/i915/intel_context.h | 1 -
src/mesa/drivers/dri/i915/intel_screen.c | 26 ---
src/mesa/drivers/dri/i915/intel_screen.h | 2 --
4 files changed, 31 deletion
We advertise 1.0 as the minimum point width size, and we probably ought
to clamp gl_PointSize to the actual range we advertise ([1,255]). In
particular, we don't seem to rasterize any points if the shader outputs
a point size smaller than 1.0, and that seems rather sketchy.
This fixes Piglit's vs
Reviewed-by: Alejandro Piñeiro
On 16/11/18 16:25, Jason Ekstrand wrote:
> ../src/intel/compiler/brw_fs_nir.cpp:3534:46: warning: comparison of integer
> expressions of different signedness: ‘unsigned int’ and ‘int’ [-Wsign-compare]
>assert(nir_intrinsic_write_mask(instr) ==
>
From: Mathias Fröhlich
Mark the up to now derived bitfield value now as primary
value by removing the underscore.
Signed-off-by: Mathias Fröhlich
---
src/mesa/main/arrayobj.c | 20 ++--
src/mesa/main/arrayobj.h | 4 ++--
src/mesa/main/attrib.c | 4 ++
From: Mathias Fröhlich
With the current VAO layout we do not need to make these
fields a bitfield. We get a tight struct layout with this change
for VAO attributes.
Signed-off-by: Mathias Fröhlich
---
src/mesa/main/mtypes.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git
From: Mathias Fröhlich
For enabling or disabling VAO arrays it is now possible to
change a set of arrays with a single call without the need to
iterate the attributes.
Make use of this technique in the vao module.
Signed-off-by: Mathias Fröhlich
---
src/mesa/main/varray.c | 38 ++
From: Mathias Fröhlich
Instead of using gl_array_attributes::Enabled use the
much more compact representation stored in
gl_vertex_array_object::Enabled using the corresponding bits.
Signed-off-by: Mathias Fröhlich
---
src/mesa/main/api_arrayelt.c | 28 ++--
src/mesa/mai
From: Mathias Fröhlich
Instead of open coding the size computation, use the
already available gl_array_attribute::_ElementSize value.
Signed-off-by: Mathias Fröhlich
---
src/mesa/tnl/t_split_copy.c | 11 ++-
1 file changed, 2 insertions(+), 9 deletions(-)
diff --git a/src/mesa/tnl/t_s
From: Mathias Fröhlich
Hi Brian,
The present series takes again care of the struct layout of the VAO.
My last spring changes here destroyed the past attempt to get a minimum size
struct layout on these structs. And with this series the property is again
established. A struct gl_vertex_attributes
From: Mathias Fröhlich
Instead of using gl_array_attributes::Enabled use the
much more compact representation stored in
gl_vertex_array_object::Enabled using the corresponding bits.
Keep the glGet changes in a seperate patch at least for review.
Signed-off-by: Mathias Fröhlich
---
src/mesa/mai
From: Mathias Fröhlich
Now that all users go via the VAO Enabled bitfield,
get rid of the Enabled boolean.
Signed-off-by: Mathias Fröhlich
---
src/mesa/main/arrayobj.c| 14 --
src/mesa/main/mtypes.h | 1 -
src/mesa/main/varray.c | 11 ---
src/mesa/vbo/vbo_sav
From: Mathias Fröhlich
Instead of open coding the size computation, use the
already available gl_array_attribute::_ElementSize value.
Signed-off-by: Mathias Fröhlich
---
src/mesa/drivers/dri/nouveau/nouveau_vbo_t.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/mesa/dr
From: Mathias Fröhlich
Factor out struct gl_vertex_format from array attributes.
The data type is supposed to describe the type of a vertex
element. At this current stage the data type is only used
with the VAO, but actually is useful in various other places.
Due to the bitfields being used, spec
From: Mathias Fröhlich
Use GL_UNSIGNED_BYTE as initialization data type
for the edge flag vertex attribute array. The same datatype
is used in the glEdgeFlagPointer function when setting the
array pointer.
Signed-off-by: Mathias Fröhlich
---
src/mesa/main/arrayobj.c | 2 +-
1 file changed, 1 i
https://bugs.freedesktop.org/show_bug.cgi?id=106958
--- Comment #12 from egon2003 ---
I have the same problem on my Vega 64. Mesa 18.3.0-rc3
I made an apitrace in Windows but I'm not sure if it works since I dont know
how to replay it.
When I try to replay it in Linux I get error: failed to exec
Rb
On November 17, 2018 03:24:13 Kenneth Graunke wrote:
This is all leftover from the i965 split.
---
src/mesa/drivers/dri/i915/intel_context.c | 2 --
src/mesa/drivers/dri/i915/intel_context.h | 1 -
src/mesa/drivers/dri/i915/intel_screen.c | 26 ---
src/mesa/drivers/dri/i
Do smaller point sizes make sense when multisampling?
On November 17, 2018 03:40:10 Kenneth Graunke wrote:
We advertise 1.0 as the minimum point width size, and we probably ought
to clamp gl_PointSize to the actual range we advertise ([1,255]). In
particular, we don't seem to rasterize any po
https://bugs.freedesktop.org/show_bug.cgi?id=106958
--- Comment #13 from egon2003 ---
Realized I had to run it under wine but wine crashes for me before i reach
where the glitches are.
--
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug._
Reviewed-by: Lionel Landwerlin
On 17/11/2018 09:24, Kenneth Graunke wrote:
This is all leftover from the i965 split.
---
src/mesa/drivers/dri/i915/intel_context.c | 2 --
src/mesa/drivers/dri/i915/intel_context.h | 1 -
src/mesa/drivers/dri/i915/intel_screen.c | 26 -
Hey Dylan,
Dylan Baker wrote on 17.11.18 05:04:
> Quoting Dylan Baker (2018-09-17 09:44:07)
>> I feel like for !windows meson is in good enough shape at this point that we
>> can start having the discussion about deleting the autotools build. So, is
>> there
>> anything left that autotools can do
Ah, that's probably where 0.125 comes from - 1/8th for 8x MSAA.
Though we advertise 1.0 as the minimum MS point width, as well.
I suppose we could try and advertise 0.125 as the minimum MSAA point
width in GLES, and use 0.125 for MSAA and 1.0 for single sampled RTs.
Advertising in GL is a bit won
Michel Dänzer writes:
Thanks for taking time to review this patch!
>> + int64_t refresh = (int64_t) refresh_timing.refreshDuration;
>> + int64_t frames = (delta_nsec + refresh/2) / refresh;
>
> desiredPresentTime has "no sooner than" semantics, so I think this should
This adds support for the VK_GOOGLE_display timing extension, which
provides two things:
1) Detailed information about when frames are displayed, including
slack time between GPU execution and display frame.
2) Absolute time control over swapchain queue processing. This allows
the appli
https://bugs.freedesktop.org/show_bug.cgi?id=107991
--- Comment #13 from John ---
This seems the same as my bug
https://bugs.freedesktop.org/show_bug.cgi?id=108771, also using Dolphin.
I hope we can get some information.
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugs.freedesktop.org/show_bug.cgi?id=107991
--- Comment #14 from kyle.de...@mykolab.com ---
Hi John,
Out of morbid curiousity, can you see if my attached apitrace causes a freeze?
As of 4.19.2, it no longer causes freezing on my RX 580, but I was reluctant to
close this issue just in cas
25 matches
Mail list logo
