Re: time for amber2 branch?
On Thu, Jun 20, 2024 at 12:02 AM Mike Blumenkrantz wrote: > * lima We do maintain this, with reliable coverage in CI, and I haven't seen feedback of it particularly causing big pain for tree wide changes before. So I'd rather keep it in the main tree. At least for this round and as long as we keep other ARM GLES2 class of drivers in the main tree as well for which we need to keep pretty much the same set of common code. Erico
Re: [Mesa-dev] [PATCH] nir: fix ir_binop_gequal glsl_to_nir conversion
On Sun, Apr 15, 2018 at 2:30 AM, Jason Ekstrand wrote: > On April 14, 2018 12:43:35 Connor Abbott wrote: > I think that it's probably impractical to use this path, and we should > probably delete it. There are just too many optimizations, e.g. in > nir_opt_algebraic and lowering passes that assume you have ints. I > think a better plan would be to silently convert ints to floats in the > lima driver, and maybe inhibit any optimizations that use bit > twiddling tricks if real int support isn't indicated. > > I'm not sure. For quite a while prog_to_nir used these comparison > operations so we know they more it less work. For all I know, maybe it > still does (I didn't actually check). The only thing we need to worry about > in terms of correctness is any optimizations in nir_opt_algebraic which > consume only floats but produce integers. Also, all drivers need to handle > imov simply because it's easy. > > That being said, we've done a lot of work to optimize the integer supporting > paths so you may actually get better code if you can figure out a good way > to lower the integers away. I'm not really using ints in my sample program, just floats. But still I'm getting nir_op_slt and nir_op_sge for the float comparison operations. Should I be getting nir_op_flt and nir_op_fge instead even with .native_integers disabled in glsl_to_nir? ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] nir: fix ir_binop_gequal glsl_to_nir conversion
On Sat, Apr 14, 2018 at 9:26 PM, Jason Ekstrand wrote: > Reviewed-by: Jason Ekstrand > > What driver is hitting this path? The !supports_ints path isn't used to my > knowledge so if some driver has started using it, they're liable to find > more bugs than just this one. :-) I'm doing some work on the lima vertex shader compiler and I hit this. And yeah this is there since 2015 it seems, so I suppose no other drivers are using this path, we'll see if there's more. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] nir: fix ir_binop_gequal glsl_to_nir conversion
ir_binop_gequal needs to be converted to nir_op_sge when native integers
are not supported in the driver.
Otherwise it becomes no different than ir_binop_less after the
conversion.
Signed-off-by: Erico Nunes
---
src/compiler/glsl/glsl_to_nir.cpp | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/compiler/glsl/glsl_to_nir.cpp
b/src/compiler/glsl/glsl_to_nir.cpp
index 17d58acc4c..8e5e9c3491 100644
--- a/src/compiler/glsl/glsl_to_nir.cpp
+++ b/src/compiler/glsl/glsl_to_nir.cpp
@@ -1832,7 +1832,7 @@ nir_visitor::visit(ir_expression *ir)
else
result = nir_uge(&b, srcs[0], srcs[1]);
} else {
- result = nir_slt(&b, srcs[0], srcs[1]);
+ result = nir_sge(&b, srcs[0], srcs[1]);
}
break;
case ir_binop_equal:
--
2.14.3
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Question about min_index/max_index calculation
Thanks all for the input. I don't have an in-depth knowledge of the hardware either, though as far as we can see the hardware does expect that we pass min_index in the command stream. max_index is used to calculate the sizes in other command stream fields (which is not the same as pipe_draw_info.count). The existing lima-ng implementation does the same: https://github.com/limadriver-ng/lima/blob/660a940c8cc151fd886559233c1a22385ee5f254/limare/lib/gp.c#L584 (draw->vertex_start). On Sat, Mar 17, 2018 at 7:23 PM, Ilia Mirkin wrote: > For an approximation, you can use the sizes of the bound vbo's to > guess a min/max index. See > https://cgit.freedesktop.org/mesa/mesa/tree/src/gallium/drivers/vc4/vc4_draw.c#n183 > for an example. I quickly played with porting something like that to mesa-lima but I don't think it can solve our problem. Apparently our bo currently have a fairly large fixed size so I'm not sure we can do an equivalent calculation using bo size. And then, min_index is required too. On Sat, Mar 24, 2018 at 10:32 PM, Marek Olšák wrote: > Here is how to do it: > > if (max_index != ~0u) >// index bounds are valid; > else >// scan the index buffer manually; > > u_vbuf_get_minmax_index can be used for the scanning. mesa-lima currently does not use any vbuf function. And we currently can't call u_vbuf_get_minmax_index since it's static in u_vbuf.c. I suppose we can consider making u_vbuf_get_minmax_index public then. I tested this and it works for me. It's still a bit annoying since we need to create fields probably in lima_context (like vc4_context.max_index does) and use those instead of the ones in pipe_draw_info. But not a big problem I guess. We could submit this refactor when mesa-lima gets proposed upstream. Just for completeness, one other idea that came up was to define a new PIPE_CAP_xxx config used to override st_context.draw_needs_minmax_index, and set that in this driver. This way, pipe_draw_info would come correctly filled and we wouldn't need to explicitly assemble minmax indices during the driver draw_vbo. How does this sound compared to the other solution? ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] Question about min_index/max_index calculation
Hi all, I have been working to add indexed drawing/glDrawElements support to the mesa-lima driver currently in development (https://github.com/yuq/mesa-lima). For that implementation, it seems that we need to have the minimum and maximum index values from the index buffer available in order to set up a proper command stream. Mesa provides these values in pipe_draw_info.min_index and pipe_draw_info.max_index, however in some cases we noticed that it decides to not calculate those. This happens because of st_context.draw_needs_minmax_index being false after evaluating the vertex data. In those cases, min_index gets to be 0 and max_index gets to be 0x. According to the gallium documentation, this seems to be on purpose and apparently drivers should be able to handle the 0 and 0x case and be able to render anyway. However, we haven't figured out a way to do the render anyway with 0 and 0x. For us it would be interesting to always have mesa calculate those values for indexed drawing. We haven't been able to figure out a way to do that without changing the mesa generic code. Is there some way we could accomplish that in driver specific code? Otherwise, can you provide some advice on how to best handle this? Using mesa 17.3 and kmscube with the following patch is one way to reproduce st_context.draw_needs_minmax_index not being set. https://gist.githubusercontent.com/enunes/366398fbee3d194deb3a46ef9c2ca78d/raw/82a2c8084236e35635b7a247609213d0068974e3/kmscube.patch The only way that this works for us with the current implementation is by hacking st_context.draw_needs_minmax_index to be always true in some way. Thanks Erico ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
