Hello all,
I am new to Mesa development (and in particular the i965 driver). I am
currently trying to gain an understanding of Mesa's implementation with mostly
an eye on (just) the i965 driver. Some questions:
There are some docs in docs, how up to date are those documents? In particular
I
Hello,
Thank you for the very fast answers, some more questions:
It's not a preference question. The registers are 8 floats wide.
Vertex shaders get invoked 2 vertices at a time, with a register containing
these values:
. +--+--+--+--+--+--+--+--+
.
Hello all,
I thank all those that have answered my questions, I still have a few more.
Here goes.
I saw that geometry shaders were landed recently in some form. My questions are:
* What is the execution style of the geometry shader on i965? (i.e. the
fragment shader is invoked 8
Hi all,
I'm not aware of any public web servers that serve up the doxygen
documentation right now. If you can find one (or set up one, or convince the
freedesktop.orghttp://freedesktop.org maintainers to set up one), I would
be in favor of putting overview style documentation in doxygen
Hi,
No, I said it would be better to use st_choose_matching_format in
st_ChooseTextureFormat,
because st_choose_matching_format does exactly what you're trying to do.
I have gone ahead and implemented what I had in mind. See the attached patch.
Marek
One thing to make sure of in the
Hi all,
I've been tracking through src/mesa/vbo and tracking down the dispatch stuff
in relation to the stuff in src/mesa/vbo. I see how the function entries in
vbo_context#exec and vbo_context#save are filled (by essentially macros defined
in of src/mesa/vbo/vbo_attrib_tmp.h interacting with
I don't know if this really matters or not, but I managed to answer my question:
for i965, there is a chain of calls so that _mesa_install_exec_vtxfmt() is
called at context creation,
which sets both Exec and BeginEnd (for compatibility profiles) to the value as
found in vbo_context#exec.
Hello all,
I really apologize, being new to git send-email and git format I managed to
make a number of mistakes when I sent the patches for documentation:
1) I sent the patch set twice.
2) The second time I sent the patch set, I sent the first patch twice.
The threads for each are
Hi all,
I've been digging through the i965 driver implementation attempting to get my
head around it. I have a few questions which I hope can be answered:
* What is LIR? The comments say that Mesa GLSL IR is converted into LIR
which in turn is converted into GPU code. What is LIR and how
Hello all,
My current goal is to add documentation to Mesa so that the ramp up time of
Mesa goes down a great deal. In addition I wish to create an index of files and
data structures keyed by subjects. The use case of such an index is of the form
How does Mesa does functionality foo? Where
If patch two was applied and this (patch three) wasn't, then mesa would
contain
less documentation than before. Idea is that every commit on its own makes
things better and never worse. Hence the addition in this patch (number three)
would need to go together with the removal done in patch
Hello all,
I've got some questions and I would appreciate if anyone could help me out.
Here goes:
I've been digging through brw_try_draw_prims(), and trying to figure out what
it is doing, so far this is what I see:
1) it is essentially called each time a non-degenerate real drawing
Hi,
Thankyou for the detailed answer, and now I have still more questions:
No. do_flush_locked() (which is called by intel_batch_buffer_flush())
follows that by calling either drm_intel_bo_mrb_exec() or
drm_intel_gem_bo_context_exec(). That's what causes the batch to be queued
for
Hi all,
I was looking at the UBO implementation for Gen7 and following the trail of
brw_vs_ubo_surfaces (found in brw_vs_surface_state.c ). The part that made me
wonder was the following trail:
834 /* Because behavior for referencing outside of the binding's size
in the
835
but I do not quite follow the second upload; what
is the magicks going on with batch-state_batch_offset and for that matter
batch-bo-size ??
This is stack and heap model for batchbuffer submission. Direct state, which
is usually composed of the commands, is allocated at the beginning and
Hi all,
I've been digging through Mesa's i965 and am at the point that I likely need
to atleast know what is the API for the intel_drm calls. Chasing the code in
DRM sources for each of the calls leaves me with essentially a function pointer
chase which then lands me with an ioctl call. The
Hi all,
I was poking through the code tracking what is happening to
brw_context::upload.bo, and it left me scrathing me head. As Paul Berry told
me, I see that is used to just store client side index and vertex buffers
(copied to it essentially be copy_array_to_vbo_array() and
Hello all,
I have been going through the Mesa source code, generating doxy-text with the
goal to make getting started in Mesa faster.
Chad has setup a public site so that anyone can see the doxygen generated
content at:
http://people.freedesktop.org/~chadversary/mesa/doxygen/kevin-rogovin/
Hi all,
I am trying to get my head around CACHED_BATCH() which is just a macro for
intel_batchbuffer_cached_advance(), and when I dig into that code it leaves me
some head scratching. I am guessing it checks if the current contents of the
batch buffer already have command and if so, to
Hi all,
As I was poking into the magicks for the batchbuffer, I saw the following
logical bits of code, that make sense by themselves but get me paranoid
together. Firstly in intel_batchbuffer_begin() [ intel_batchbuffer.h, and this
is what BEGIN_BATCH maps to] there is a
To: Rogovin, Kevin; mesa-dev@lists.freedesktop.org
Subject: Re: [Mesa-dev] Batchbuffer question
On 11/08/2013 04:49 AM, Rogovin, Kevin wrote:
Hi all,
As I was poking into the magicks for the batchbuffer, I saw the
following logical bits of code, that make sense by themselves but get
me paranoid
for the purpose of debug; going further those members will only
exists in debug
for that matter.
From: Eric Anholt [e...@anholt.net]
Sent: Monday, November 11, 2013 9:56 PM
To: Rogovin, Kevin; mesa-dev@lists.freedesktop.org
Cc: Rogovin, Kevin
Subject: Re: [Mesa
at intel.com
Mon Nov 11 23:26:47 PST 2013
with commit message:
Track bytes written during no flush phases for debug builds
-Kevin
From: Rogovin, Kevin
Sent: Tuesday, November 12, 2013 8:39 AM
To: mesa-dev@lists.freedesktop.org
Subject: RE: [Mesa-dev
Hello all,
I see from the quasi-doxytags that CurrentFragmentProgram is for separate
shader objects to point to the active fragment program for essentially
glActiveShaderProgram, but what is _CurrentFragmentProgram? and for that
matter, I also see that CurrentFragmentProgram and sometime
Hello all,
Yet another questions related to i965. I was taking a gander through the code
base hunting down where and how uniforms are uploaded to the GPU; what I do see
is that pointers are set directly to the a backing store that holds the uniform
values:
brw_vec4_prog_data::param array of
Hi all,
I was taking a look in i965 taking a closer look at the upload to GPU of
param and pull_param for vertex shaders. What I found was this:
1) in vec4_visitor::move_uniform_array_access_to_pull_constants(), those
uniforms that are relatively addressed are cloned from param to
be done on a patch by patch basis?
Best Regards
-Kevin Rogovin
From: Kenneth Graunke [kenn...@whitecape.org]
Sent: Tuesday, December 03, 2013 10:49 AM
To: Rogovin, Kevin; mesa-dev@lists.freedesktop.org
Subject: Re: [Mesa-dev] [PATCH 1/2] Allow for GLSL
Hi,
Yeah...there's a point where you switch from the old code to the new
code, and most bugs would probably bisect to that. In this case, I
think that's fairly unavoidable.
However, splitting it up into multiple patches would definitely make it
a lot easier to review.
So, is it required
]
Sent: Tuesday, December 03, 2013 11:44 AM
To: Rogovin, Kevin; mesa-dev@lists.freedesktop.org
Subject: Re: [Mesa-dev] [PATCH 1/2] Allow for GLSL shaders to have #extension
directive anywhere in source file.
On 12/03/2013 12:00 AM, Kevin Rogovin wrote:
[snip]
diff --git a/src/glsl/glcpp
Okay if we make this the subject?
mesa: Allow depth = 0 parameter for TexImage3D.
Sure, that is fine and more succinct.
-Kevin
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
@@ -487,6 +486,7 @@ setup_shader_for_sampler(struct gl_context *ctx, struct
glsl_sampler
*sampler)
void main()\n
{\n
gl_FragColor = %s(texSampler, %s);\n
+
?
or possible fancier filtering kernels?
Best Regards,
-Kevin Rogovin
From: Ian Romanick [i...@freedesktop.org]
Sent: Sunday, February 02, 2014 5:45 PM
To: Rogovin, Kevin; mesa-dev@lists.freedesktop.org
Subject: Re: [Mesa-dev] [PATCH 26/35] meta: Use common GLSL
I don't believe our hardware can support GL_ARB_shader_stencil_export.
The render target write message can take RGBA, depth, and sample masks,
but not stencil. Without that, it's not at all obvious how to implement it.
There is a terrible hack-ish way to do it, but I stress the word
]
Sent: Wednesday, February 05, 2014 6:02 AM
To: Rogovin, Kevin; mesa-dev@lists.freedesktop.org
Subject: Re: [Mesa-dev] [PATCH] centroid affects interpolation
On 02/04/2014 05:01 AM, Kevin Rogovin wrote:
Place centroid keyword as an interpolation qualifier.
Previously was a storage qualifier
Hi,
I was looking over the _mesa_meta_BlitFramebuffer and in particular,
blitframebuffer_texture(). A few idea (feedback welcome and wanted):
Firstly, the check if src is a renderbuffer or not. I think it might be a good
idea to add an internal Mesa API to allow a driver to specify that a
Hi,
Um, please ignore the 1st suggestion; it was already in Mesa and I was not
awake of enough. Sighs.
From: Rogovin, Kevin
Sent: Monday, February 10, 2014 12:06 PM
To: mesa-dev@lists.freedesktop.org
Cc: Romanick, Ian D
Subject: Texture from RenderBuffer
Hi,
I was doing some experiments and had linking issues with C++ code and saw that
some Mesa header files have extern C wrappers and others do not. For example
running:
$ find src/mesa/main -type f -name *.h -exec grep -H -E -o -c extern
\C\ {} \; | grep :0 | wc -l
gives a result of 109
I'll post a corrected patch shortly, but first some answer to questions:
Have you found an application that wants these extensions? That might
be useful to describe in the commit message.
There are some occasional bits in Qt that uses HALF_FLOAT_OES for GLES2 (but I
stress it is not a often
Hi,
The patch basically looks good. We're lacking piglit tests for these
extensions, and I think we'll want some before we turn these extensions on.
Thanks for the review. Should I make the necessary piglit tests?
These extensions still aren't sorted into the GL_OES_* list. I'll just do
of the
OES extensions without needing to support the ARB extension.
-Kevin
From: Marek Olšák [mar...@gmail.com]
Sent: Friday, May 16, 2014 4:33 PM
To: Rogovin, Kevin
Cc: mesa-dev@lists.freedesktop.org
Subject: Re: [Mesa-dev] [PATCH] mesa: Expose
Hi
It should be possible to adapt some of the existing float texture tests
to run on ES mode without too much effort.
Oh dear, the test makes the GL API convert between 16 and 32 bit float formats.
Also it does not appear to test filtering either.
Would it be prudent to make 4 tests: one for
support.
-Kevin
Marek
On Mon, May 19, 2014 at 8:34 AM, Rogovin, Kevin kevin.rogo...@intel.com
wrote:
Hi,
Each of the four extensions are right now set to be advertised if and only
if a GL context would advertise GL_ARB_texture_float:
{ GL_OES_texture_float, o
Hi,
A long time ago back in the beginning of May
I submitted a patch to add to Mesa's support
for the GLES2 extensions:
GL_OES_texture_float,
GL_OES_texture_half_float,
GL_OES_texture_float_linear and
GL_OES_texture_half_float_linear
A linky to the post is here:
Hi,
A long time back in May, I made a very small patch to the GLSL pre-processor
to define the symbol GL_OES_standard_derivatives (as 1), if the extension is
supported. Without that patch, shaders that detect if they can use dFdx, dFdy
and fwidth via #ifdef's do not function correctly (namely
Please ignore posting: [PATCH] i965:Fix intel_mipmap_copy_teximage for
GL_TEXTURE_1D_ARRAY.
Sighs. I had put the wrong directory when git send-email. My big apologies for
the idiot-noise.
However, please do NOT ignore the patch series for
ARB_framebuffer_no_attachment.
Best Regards,
-Kevin
-Original Message-
From: ibmir...@gmail.com [mailto:ibmir...@gmail.com] On Behalf Of Ilia Mirkin
Sent: Friday, April 24, 2015 4:36 PM
To: Matt Turner
Cc: Rogovin, Kevin; mesa-...@freedesktop.org
Subject: Re: [Mesa-dev] [PATCH 2/7] Define constants and functions
Actually I realized that you add quite a bit of support to gen4-6 logic that
_isn't_ used for gen7 and higher. In the last patch of the series you claim
to enable this only for gen7 and higher - I'm confused.
There are two reasons:
1. Because atoms get reused all the time across
I'll check with Jordan and others. I have a faint recollection that compute
shaders have similar
needs. I think your change is fine though, I just want to understand the
bigger picture first.
I do not think compute shaders have similar needs. These flags are for making
sure the
My point specifically was that you are also updating atoms that _are not_
re-used.
And as those changes are not really needed, I wouldn't take the risk of
changing
something in vain. I would introduce them only when you have patches to
really enable older generations.
My take is the
is present in both gen7_atoms
and gen8_atoms.
I would argue that _CurrentFragmentProgram can be NULL, given
that other places check for it and that without the check piglit gets
about 30 more crashes.
Sorry for not posting this in the first reply.
-Kevin
-Original Message-
From: Rogovin
Checking brw-ctx.Shader._CurrentFragmentProgram != NULL is unnecessary.
There is always a valid pixel shader. (If the application is using
fixed-function, we supply a fragment shader for them.) Please drop that
check.
Without this check(in the Gen7 function/code), about 30 crashes are
programming the rasterizer/windower
thingies.
-Kevin
-Original Message-
From: Rogovin, Kevin
Sent: Friday, April 24, 2015 7:43 PM
To: Pohjolainen, Topi
Cc: mesa-...@freedesktop.org
Subject: RE: [Mesa-dev] [PATCH 5/7] i965: use
_mesa_geometry_width/height/layers/samples for programming geometry
Hi,
This is in fact two changes: introduction of the helpers and refactoring of
the intersection code to be used with caller provided bounding box.
Is this a request to change the commit message or to split this as well?
I think splitting it is silly, but if it make you happy so be it; the
, 2015 at 11:06 AM, Rogovin, Kevin kevin.rogo...@intel.com
wrote:
Hi,
I agree with the comments about the code (and when the last element of the
series is reviewed I will submit the series with review comments taken into
use), but when I applied just Patch 1 and Patch 2, and ran
src/mesa
Hello,
No, because the non-shared code is (by your own admission) untested and/or
dead code. Untested code is broken code. I would personally be ok with a
lot of the changes that just replace fb-Width with
_mesa_geometric_width(fb) since it's effectively just replacing a direct
access
I read the patch again and I'm still in the opinion that the changes to the
pure pre-gen7 logic (i.e., logic that is not re-used for later gens) are not
needed.
As I have tried and apparently failed to communicate, it is -better- and more
consistent. Need
is a far stronger word. Without a
When you rebase this, I'd appreciate it if you could insert it into
the list in alphabetical order. (You based this on a commit where a
bunch of the later additions were already not inserted alphabetically,
but I've recently fixed that up.)
Sure, no worries. Given that I am just changing the
Hi,
I'd just go read the ES 3.1 spec and see if there are any differences in this
area.
I checked the spec, and it appears to me to have the same behavior as
GL_ARB_framebuffer_no_attachments.
Also, please fix your mail client to stop its weird line wrapping (and the
other half of the
I just want to make a begging on the review for this patch: I am a touch
paranoid
about how the thing will act under the GL ES situation; I believe it should
follow
the spec, but if whoever reviews does the extra leg work of checking that I got
this
right, I'd really appreciate it.
Hi,
One comment on the code, or rather a request to the reviewer of the code. The
icky part of checking this patch is correct is checking that the remaining
instances of gl_framebuffer::Width, Height, MaxNumLayers and Visaul.samples are
correct. I believe I got 'em all, of those that should
-Original Message-
From: Pohjolainen, Topi
Sent: Monday, April 27, 2015 10:43 AM
To: Rogovin, Kevin
Cc: mesa-...@freedesktop.org
Subject: Re: [Mesa-dev] [PATCH 5/7] i965: use
_mesa_geometry_width/height/layers/samples for programming geometry of
framebuffer to GEN
On Fri, Apr 24, 2015
At the bottom is another block with GLES 3.1 requirements, which also
contains GL_ARB_f_n_a.
At first, I said Oh futz, I did not mark that one. Then I did some thinking.
Before expressing
my thoughts I want to emphasize that I really do not know what is the best
answer, or
potentially even
Hi,
A couple of us chatted about this, and we all agreed that it's probably not
useful to
enable ARB_framebuffer_no_attachments on pre-Gen7. We don't expose atomics,
SSBOs,
or image load/store on those platforms (and probably won't), so the
only way fragment shaders can output any data
One more question:
for patch 2 of the series, there was the request to change the type of
_HasAttachments from GLboolean to bool. If the helper functions survive,
should the helper functions return unsigned int instead of GLuint?
-Kevin
-Original Message-
From: Rogovin, Kevin
Sent
HI,
For both this and get_framebuffer_parameteriv below, I don't see the value in
splitting the implementations. Also, these functions need to check that the
extension is enabled and generate GL_INVALID_OPERATION if it is not.
No worries, I can add the GL_INVALID_OPERATION bit in. I have
I'm waffling about this a bit. I'm concerned that people will use
buffer-Width when they should use the accessor. I don't see any
changes to core Mesa code to use the accessor, so I'm a little concerned that
some subtle, incorrect behavior is introduced... but there may well not be.
A
You haven't been running 'make check'. :) You also need to update
src/mesa/tests/dispatch_sanity.cpp.
There is something wrong with my box or something... I did run make check and
there were no failures. Out of paranoia, I also ran
src/mesa/main/tests/main-test explicitly and there were no
Hi,
I think this check should be put in a utility function up in core Mesa
somewhere. It's open-coded twice in this patch, and the check will change
when GL_ARB_image_load_store lands.
Would a check of the form:
inline bool
_mesa_has_atomic_ops(struct gl_context *ctx)
{
return ctx-
, all drivers now use the field from
Visual. If gl_framebuffer::Samples or potentially a better named
gl_framebuffer::_Samples is added, then should the field be removed from Visual
and all references in drivers to use the new field?
-Kevin
-Original Message-
From: Rogovin, Kevin
Sent
-Original Message-
From: Rogovin, Kevin
Sent: Wednesday, June 10, 2015 8:56 AM
To: 'Ian Romanick'; mesa-dev@lists.freedesktop.org
Subject: RE: [Mesa-dev] [v4 PATCH 05/10] mesa: helper function for scissor box
of gl_framebuffer
Hi,
-Original Message-
From: Ian Romanick
Hi,
-Original Message-
From: Ian Romanick [mailto:i...@freedesktop.org]
Sent: Wednesday, June 10, 2015 1:06 AM
To: Rogovin, Kevin; mesa-dev@lists.freedesktop.org
Subject: Re: [Mesa-dev] [v4 PATCH 05/10] mesa: helper function for scissor box
of gl_framebuffer
All of the changes
Hi,
44 instances of a leading + in mesa/main compared to 78 trailing ones.
Huh, I was going to say that it's really uncommon to do this in mesa, but
that may not be supported by fact.
Considering there is a formatting issue below, I can change it to trailing. I
don’t care.
+ if (ymax
You should wait until you get a real review from someone before reposting.
I think that is good advice. Indeed, I am not going to post a v5 of this series
until for each patch there is:
Two review bys, possibly qualified with fix the mentioned formatting issues
OR
Specific change requests.
Hi,
+static inline GLuint
Here and below, why 2 spaces between inline and GLuint?
I have no clue. I suspect it is a scar from some search/replace fiasco over 3
weeks ago. You are the first person who spotted that nit.
--- a/src/mesa/main/mtypes.h
+++ b/src/mesa/main/mtypes.h
@@ -3187,7
Out of curiosity, what editor are you using? Usually setting the
indentation rules in your editor takes care of most of these problems.
I am using emacs23 (under Ubuntu) and now for something amusing...
We have a .dir-locals.el file that should provide the correct settings
for Emacs.
I'm happy to see new documentation, so thanks for writing it up!
But let's separate this from the functional changes related to implementing
the extension. (Didn't I give this comment last time?)
If you did, I missed it. Unless there are objections, I'll remove this from the
series and
Extra space between . and
Fix I will
Extra space before .
Fix I will
Also, if anyone is ever grepping for MAX_FRAMEBUFFER_SAMPLES, they won't find
this. I'd move the whole word to the next line.
Ok.
+ *
+ * The same requirements are also in place for GL 4.5,
+ *
This line is too long. (It will not fit in 80 columns in git log since git
log adds some spaces before each commit message line.)
What is the accepted maximum length for a line in a commit message?
- extension table
- additions to gl_framebuffer
v1 - v2
Spacing and trailing spaces
src/mesa/drivers/dri/i965/brw_misc_state.c | 10 +++---
src/mesa/drivers/dri/i965/brw_sf_state.c | 8
As is this?
brw_misc_state.c is active for all Gens. The change to brw_sf_state.c is to
add a comment warning that using gl_framebuffer::Width and so on is
HI,
Or 78 columns, to be safe, but there's exceptions, like if you're
defining a big static table/array of info.
Uggg I don't mind exceptions, but knowing them is key.
4. successive parenthesis must have spaces between parenthesis
Example?
if (some_func(some_argument))
is
Strange because of the types -- presumably fb_samples is an int because its
uses are in a comparison with another int (that probably doesn't need to be
an int :)
I am really hesitant to start changing types all over the place; I have a
sinking suspicion that changing the types of fb_width,
I suppose it could be useful, but I think we've been mostly successful at
just expecting people to recognize when what they're writing doesn't look
like the code around it.
This is my point. Older code had different style/expectations than newer code.
For this patch series, I have hit a
FWIW, the kernel standards for commit messages are at:
https://www.kernel.org/doc/Documentation/SubmittingPatches
Most of those rules apply to Mesa too. It says the body should be wrapped to
75 chars (although I've been using 72 like Matt said).
This is my point: use most rules, but not
Reviewed-by: Kevin Rogovin kevin.rogovin at intel.com
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Reviewed-by: Kevin Rogovin kevin.rogovin at intel.com
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Hello,
> typo -> ...query (same goes for patch 1/2)
I hate typos. Thanks for pointing it out.
> Please correct me if I'm wrong, but I think we cannot unalias functions once
> they're in.
> It will break the backwards compatibility we're trying to manage with glapi.
> If we want to
> retain
, August 24, 2017 8:10 PM
To: Rogovin, Kevin <kevin.rogo...@intel.com>
Cc: mesa-dev@lists.freedesktop.org
Subject: Re: [Mesa-dev] [PATCH] i965: add 2xMSAA and 16xMSAA to DRI configs for
Gen9.
On 17-08-24 14:16:39, kevin.rogo...@intel.com wrote:
>From: Kevin Rogovin <kevin.rogo...@intel.com
fixes for the issue that Chris pointed out
on batchbuffer migration and a pair of issues I realized on the script at patch
17).
Best Regards,
-Kevin
-Original Message-
From: Rogovin, Kevin
Sent: Wednesday, September 27, 2017 2:38 PM
To: Chris Wilson <ch...@chris-wilson.co.uk>
: Tuesday, September 26, 2017 2:53 AM
To: Landwerlin, Lionel G <lionel.g.landwer...@intel.com>; Rogovin, Kevin
<kevin.rogo...@intel.com>; mesa-dev@lists.freedesktop.org
Subject: Re: [Mesa-dev] [PATCH 05/22] i965: correctly assign SamplerCount of
INTERFACE_DESCRIPTOR_DATA
On 2017-09-25 05:4
. When the value is zero, it means the GPU will not prefetch the
binding table entries.
-Kevin
-Original Message-
From: Landwerlin, Lionel G
Sent: Monday, September 25, 2017 3:10 PM
To: Rogovin, Kevin <kevin.rogo...@intel.com>; mesa-dev@lists.freedesktop.org
Subject: Re: [Mesa-dev]
file).
Let me know, what is best, and I will do it.
-Kevin
-Original Message-
From: Chris Wilson [mailto:ch...@chris-wilson.co.uk]
Sent: Tuesday, September 26, 2017 11:20 PM
To: Rogovin, Kevin <kevin.rogo...@intel.com>; mesa-dev@lists.freedesktop.org
Subject: Re: [Mesa-dev] [PAT
is to send the api-trace call id's to the kernel on
execbuffer2, then this does not matter.
-Kevin
-Original Message-
From: Rogovin, Kevin
Sent: Wednesday, September 27, 2017 9:53 AM
To: 'Chris Wilson' <ch...@chris-wilson.co.uk>; mesa-dev@lists.freedesktop.org
Subject: RE: [Me
Sent: Wednesday, September 27, 2017 12:35 PM
To: Rogovin, Kevin <kevin.rogo...@intel.com>; Chris Wilson
<ch...@chris-wilson.co.uk>; mesa-dev@lists.freedesktop.org
Subject: Re: [Mesa-dev] [PATCH 00/22] RFC: Batchbuffer Logger for Intel GPU
A few months ago I implemented debug messages in
make such a dedicated tool quite quickly, or add that
functionality to the logger.
-Kevin
-Original Message-
From: Chris Wilson [mailto:ch...@chris-wilson.co.uk]
Sent: Wednesday, September 27, 2017 1:21 PM
To: Rogovin, Kevin <kevin.rogo...@intel.com>; mesa-dev@lists.freedeskt
>My worry is that batch->bo is not constant for the construction of a single
>execbuf2.
> If intel_batchbuffer.c runs out of room inside the batch->bo, it will
> allocate a new one and continue building it.
That will be ok, but if the (fd, GEM BO handle) changes, there is a serious
issue.
>
Hi,
I do not know if anyone has noticed or if it is deliberate, but the meson
builds have that assert()'s are active but the autotools release builds have
that assert() is inactive.
-Kevin
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
: Matt Turner [mailto:matts...@gmail.com]
Sent: Monday, November 13, 2017 11:21 PM
To: Rogovin, Kevin <kevin.rogo...@intel.com>
Cc: mesa-dev@lists.freedesktop.org
Subject: Re: [Mesa-dev] [PATCH 07/18] intel/compiler: fix for memmove argument
on annotating error
On Mon, Nov 13, 2017 at 1
level
that only one of the two is possible without texture invalidates.
-Kevin
-Original Message-
From: Topi Pohjolainen [mailto:topi.pohjolai...@gmail.com]
Sent: Monday, December 4, 2017 12:49 PM
To: mesa-dev@lists.freedesktop.org
Cc: Rogovin, Kevin <kevin.rogo...@intel.com>
S
> If you take a look at brw_update_texture_surface(), just in the end before
> brw_emit_surface_state() the logic explictly consults for
> intel_miptree_texture_aux_usage().
> This in turn tells if the auxiliary buffer is resolved and it doesn't need to
> be programmed.
The full stack trace
Hi,
>> Here are my comments of the patch posted:
>>
>> 1. it is essentially replication and moving around of the code of the
>> patch series posted earlier but missing various
>> important bits: preventing the sampler from using the auxiliary buffer
>> (this requires to modify surface
1 - 100 of 148 matches
Mail list logo
