Hello Dieter,
I guess you did a release build? The build failure should be fixed now,
someone else had already opened an issue.
> Maybe I can do some testing with my Tursk for you.
Thanks, that always helps :)
Best,
Gert
___
dri-devel mailing
Hello,
I'm trying to update from the kernel 4.17.17 to 5.3 on a Utilite pro
(GC2000) but I'm running a bit into trouble:
When on 4.17.17 I can run X11 with the armada driver and I get proper
OpenGL, with 5.3, the same user space, and the same kernel config
querying the chip specs via
On evergreen depth-stencil textures are allocated as two objects, and
when using the eg_surface_init_1d_miptrees code path the size evaluation
uses the generalized surf_minify function. Here when allocating the
depth texture the alignment takes the depth bpe value into account, and
uses bpe=1 for
set/gl_stencil_index8, npot
texwrap formats/gl_stencil_index8, npot
ext_framebuffer_multisample
accuracy all_samples stencil_resolve small depthstencil
unaligned-blit * stencil downsample
ext_texture_array/fbo-depth-array *stencil
Signed-off-by: Gert Wollny
---
rad
It seems I did a wrong indication in the subject,
Am Montag, den 06.08.2018, 10:13 +0200 schrieb Gert Wollny:
> On evergreen depth-stencil textures are allocated as two objects, and
> when using the eg_surface_init_1d_miptrees code path the size
> evaluation
> uses the generalized
From: Gert Wollny
On evergreen depth-stencil textures are allocated as two objects, and
when using the eg_surface_init_1d_miptrees code path the size evaluation
uses the generalized surf_minify function. Here when allocating the
depth texture the alignment takes the depth bpe value into account
.functional.texture.border_clamp.per_axis_wrap_mode.texture_2d
.uint_stencil.nearest.s_clamp_to_edge_t_clamp_to_border_npot
.uint_stencil.nearest.s_repeat_t_clamp_to_border_npot
.uint_stencil.nearest.s_mirrored_repeat_t_clamp_to_border_npot
Signed-off-by: Gert Wollny
---
Thanks for reviewing and any comments,
Gert
PS: - I have
