Would this be a win for a game limited by the winsys/buffer handling? I played some Hitman the other day, and noticed my gpu-utilization was hovering at about 80%. Some profiling later and I concluded that one thread was pegged at 100% doing buffer handling work. amdgpu_cs_add_buffer, amdgpu_lookup_buffer, the cso_hash, and a couple other functions related to the winsys where the hottest. Should I expect that to be mitigated by your threaded_gallium work, or by this patch series? If so, I will not delve into that much further =)
Oh, and excuse me if I'm totally of track here. Just starting to make sense of the gallium stuff, as I've just recently acquired a couple radeon powered PC's =) 2017-05-15 16:41 GMT+02:00 Marek Olšák <mar...@gmail.com>: > From: Marek Olšák <marek.ol...@amd.com> > > Before: DrawElements (16 VBOs) w/ no state change: 4.34 million/s > After: DrawElements (16 VBOs) w/ no state change: 8.80 million/s > > This inefficiency was uncovered by Timothy Arceri's no_error work. > --- > src/mesa/main/api_validate.c | 15 ++++++++++++++- > 1 file changed, 14 insertions(+), 1 deletion(-) > > diff --git a/src/mesa/main/api_validate.c b/src/mesa/main/api_validate.c > index cbb2361..b804e05 100644 > --- a/src/mesa/main/api_validate.c > +++ b/src/mesa/main/api_validate.c > @@ -236,21 +236,34 @@ _mesa_valid_to_render(struct gl_context *ctx, const > char *where) > /** > * Check if OK to draw arrays/elements. > */ > static bool > check_valid_to_render(struct gl_context *ctx, const char *function) > { > if (!_mesa_valid_to_render(ctx, function)) { > return false; > } > > - if (!_mesa_all_buffers_are_unmapped(ctx->Array.VAO)) { > + /* Section 6.3.2 from the GL 4.5: > + * "Any GL command which attempts to read from, write to, or change > + * the state of a buffer object may generate an INVALID_OPERATION error > if > + * all or part of the buffer object is mapped ... However, only commands > + * which explicitly describe this error are required to do so. If an > error > + * is not generated, such commands will have undefined results and may > + * result in GL interruption or termination." > + * > + * Only some buffer API functions require INVALID_OPERATION with mapped > + * buffers. No other functions list such an error, thus it's not required > + * to report INVALID_OPERATION for draw calls with mapped buffers. > + */ > + if (!ctx->Const.AllowMappedBuffersDuringExecution && > + !_mesa_all_buffers_are_unmapped(ctx->Array.VAO)) { > _mesa_error(ctx, GL_INVALID_OPERATION, > "%s(vertex buffers are mapped)", function); > return false; > } > > /* Section 11.2 (Tessellation) of the ES 3.2 spec says: > * > * "An INVALID_OPERATION error is generated by any command that > * transfers vertices to the GL if the current program state has > * one but not both of a tessellation control shader and tessellation > -- > 2.7.4 > > _______________________________________________ > mesa-dev mailing list > mesa-dev@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/mesa-dev _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev