Re: [Mesa-dev] [PATCH v2 1/2] mesa/es3.1: Expose GL_ARB_framebuffer_no_attachments to GLES 3.1

Reviewed-by: Kevin Rogovin ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH v2 2/2] mesa/es3.1: Limit Framebuffer Parameter OpenGL ES 3.1 usage

Reviewed-by: Kevin Rogovin ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] Choosing texture internal format in GLES

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 th

[Mesa-dev] Dispatch table question: VBO

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

Re: [Mesa-dev] Dispatch table question: VBO

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. T

[Mesa-dev] My apologies: I double sent patches

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 labele

[Mesa-dev] i965 driver questions

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 i

[Mesa-dev] Documentation plan: request for comments

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 a

Re: [Mesa-dev] [PATCH 3/3] doxy-text files added

> 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 pa

[Mesa-dev] Batch buffer sizes, flushing questions

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" glDr

Re: [Mesa-dev] Batch buffer sizes, flushing questions

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

[Mesa-dev] Uniform Buffer Object implementation questions

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

Re: [Mesa-dev] Batch buffer sizes, flushing questions

>> 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 beginni

[Mesa-dev] Intel DRM API Reference?

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 i

[Mesa-dev] brw_context::upload questions

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 brw_upload_ind

[Mesa-dev] Request for fedback

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/

[Mesa-dev] CACHED_BATCH questions

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 skip

[Mesa-dev] Batchbuffer question

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 intel_batchbuffer_req

Re: [Mesa-dev] Batchbuffer question

PM 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

Re: [Mesa-dev] [PATCH] nicer-no-wrap-patch

occurs in debug, since the assert is only 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.freedes

Re: [Mesa-dev] [PATCH] nicer-no-wrap-patch

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] _CurrentFragmentProgram vs CurrentFragmentProgram

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 _Cur

[Mesa-dev] i965 uniform upload question

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

[Mesa-dev] GL_OES_texture_float and GL_OES_texture_half_float support

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: http://lists.freedeskto

[Mesa-dev] GL_OES_standard_derivatives define

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 the

[Mesa-dev] a newbie asking newbie questions

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 sa

Re: [Mesa-dev] a newbie asking newbie questions

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: > > . +--+--+--+--+--+--+--+--+ >

[Mesa-dev] More questions from a newbie

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 frag

Re: [Mesa-dev] More questions from a newbie

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.org >maintainers to set up one), I would >be in favor of putting overview style documentation in doxyge

[Mesa-dev] Question: in i965 question, potential bug pull vs push constants in vertex shader

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 pull_para

Re: [Mesa-dev] [PATCH 1/2] Allow for GLSL shaders to have #extension directive anywhere in source file.

an 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

Re: [Mesa-dev] [PATCH 1/2] Allow for GLSL shaders to have #extension directive anywhere in source file.

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 requ

Re: [Mesa-dev] [PATCH 1/2] Allow for GLSL shaders to have #extension directive anywhere in source file.

] 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/gl

Re: [Mesa-dev] [PATCH] Correct test for depth parameter for checking if dimension is legal

> 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

Re: [Mesa-dev] [PATCH 26/35] meta: Use common GLSL code for blits

> @@ -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" > +

[Mesa-dev] extern "C" sometimes in header files but not always..

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

Re: [Mesa-dev] [PATCH] GL_OES_texture_float and GL_OES_texture_half_float support

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

Re: [Mesa-dev] [PATCH] mesa: Expose GL_OES_texture_float and GL_OES_texture_half_float.

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 d

Re: [Mesa-dev] [PATCH] mesa: Expose GL_OES_texture_float and GL_OES_texture_half_float.

Mesa, then do the "right" thing to allow a backend to support a subset 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: me

Re: [Mesa-dev] [PATCH] mesa: Expose GL_OES_texture_float and GL_OES_texture_half_float.

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 fo

Re: [Mesa-dev] [PATCH] mesa: Expose GL_OES_texture_float and GL_OES_texture_half_float.

rect) and then a subsequent patch, after some discussion, to support situations like the r300 partial floating point texture support. -Kevin > Marek > > On Mon, May 19, 2014 at 8:34 AM, Rogovin, Kevin > wrote: >> Hi, >> >> Each of the four extensions a

Re: [Mesa-dev] [PATCH 26/35] meta: Use common GLSL code for blits

he number of samples? 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/

Re: [Mesa-dev] [PATCH 26/35] meta: Use common GLSL code for blits

> 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 terri

Re: [Mesa-dev] [PATCH] centroid affects interpolation

h Graunke [kenn...@whitecape.org] 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 wa

[Mesa-dev] Texture from RenderBuffer for blitting

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 re

Re: [Mesa-dev] Texture from RenderBuffer for blitting

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 for

Re: [Mesa-dev] [PATCH 2/2] Differentiate between DeleteQueries and DeleteQueriesARB

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 i

Re: [Mesa-dev] [PATCH 5/7] i965: use _mesa_geometry_width/height/layers/samples for programming geometry of framebuffer to GEN

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 d

Re: [Mesa-dev] [PATCH 4/7] helper-conveniance functions for drivers to implement ARB_framebuffer_no_attachment

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

Re: [Mesa-dev] [PATCH 2/7] Define constants and functions for ARB_framebuffer_no_attachment extension

I wrote the patch 3 so that it is trivial to implement the DSA function though. -Kevin On Fri, Apr 24, 2015 at 11:06 AM, Rogovin, Kevin 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 co

Re: [Mesa-dev] [PATCH 5/7] i965: use _mesa_geometry_width/height/layers/samples for programming geometry of framebuffer to GEN

> 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

Re: [Mesa-dev] [PATCH 5/7] i965: use _mesa_geometry_width/height/layers/samples for programming geometry of framebuffer to GEN

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 >

Re: [Mesa-dev] [PATCH 9/9] mark GL_ARB_framebuffer_no_attachments as done for i965

> 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 ev

Re: [Mesa-dev] [PATCH 9/9] mark GL_ARB_framebuffer_no_attachments as done for i965

> 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 t

Re: [Mesa-dev] [PATCH 9/9] mark GL_ARB_framebuffer_no_attachments as done for i965

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

Re: [Mesa-dev] [PATCH 3/9] mesa: Complete implementation for GL_ARB_framebuffer_no_attachments in Mesa core

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. _

Re: [Mesa-dev] [PATCH 6/9] i965: Use _mesa_geometry_ functions appropriately

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 shoul

Re: [Mesa-dev] [PATCH 3/9] mesa: Complete implementation for GL_ARB_framebuffer_no_attachments in Mesa core

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 ha

Re: [Mesa-dev] [PATCH 4/9] mesa: add helper convenience functions for fetching geometry of gl_framebuffer

> 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. >

Re: [Mesa-dev] [PATCH 2/9] mesa:Define constants and functions for GL_ARB_framebuffer_no_attachment extension

> 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

Re: [Mesa-dev] [PATCH 4/9] mesa: add helper convenience functions for fetching geometry of gl_framebuffer

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, K

Re: [Mesa-dev] [PATCH 7/9] i965: ensure execution of fragment shader when fragment shader has atomic buffer access

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-

Re: [Mesa-dev] [PATCH 4/9] mesa: add helper convenience functions for fetching geometry of gl_framebuffer

urally, 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

Re: [Mesa-dev] [v3 PATCH 02/10] mesa:Define constants and functions for ARB_framebuffer_no_attachment extension

> 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 m

Re: [Mesa-dev] [v3 PATCH 03/10] mesa: Complete implementation for ARB_framebuffer_no_attachments in Mesa core

> 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, > +

Re: [Mesa-dev] [v3 PATCH 06/10] i965: Use _mesa_geometry_ functions appropriately

>> 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 o

Re: [Mesa-dev] [v3 PATCH 01/10] mesa:Define extension ARB_framebuffer_no_attachments

> 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 trail

Re: [Mesa-dev] [v3 PATCH 06/10] i965: Use _mesa_geometry_ functions appropriately

> 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

Re: [Mesa-dev] [v3 PATCH 01/10] mesa:Define extension ARB_framebuffer_no_attachments

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

Re: [Mesa-dev] [v3 PATCH 01/10] mesa:Define extension ARB_framebuffer_no_attachments

> 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

Re: [Mesa-dev] [v3 PATCH 01/10] mesa:Define extension ARB_framebuffer_no_attachments

> 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 no

Re: [Mesa-dev] [v4 PATCH 05/10] mesa: helper function for scissor box of gl_framebuffer

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 (

Re: [Mesa-dev] [v4 PATCH 04/10] mesa: add helper functions for geometry of gl_framebuffer

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 >>

Re: [Mesa-dev] [v4 PATCH 04/10] mesa: add helper functions for geometry of gl_framebuffer

> 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 reques

Re: [Mesa-dev] [v4 PATCH 05/10] mesa: helper function for scissor box of gl_framebuffer

> 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. e

Re: [Mesa-dev] [v4 PATCH 05/10] mesa: helper function for scissor box of gl_framebuffer

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

Re: [Mesa-dev] [v4 PATCH 05/10] mesa: helper function for scissor box of gl_framebuffer

-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: Ia

[Mesa-dev] Please ignore posting: [PATCH] i965:Fix intel_mipmap_copy_teximage for GL_TEXTURE_1D_ARRAY

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 __

Re: [Mesa-dev] [PATCH 2/7] Define constants and functions for ARB_framebuffer_no_attachment extension

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 function

Re: [Mesa-dev] [PATCH 5/7] i965: use _mesa_geometry_width/height/layers/samples for programming geometry of framebuffer to GEN

> 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 generatio

Re: [Mesa-dev] [PATCH 5/7] i965: use _mesa_geometry_width/height/layers/samples for programming geometry of framebuffer to GEN

> 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

Re: [Mesa-dev] [PATCH 6/7] i965: ensure execution of fragment shader when fragment shader has atomic buffer access

> 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 rast

Re: [Mesa-dev] [PATCH 6/7] i965: ensure execution of fragment shader when fragment shader has atomic buffer access

> 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 a

Re: [Mesa-dev] [PATCH 5/7] i965: use _mesa_geometry_width/height/layers/samples for programming geometry of framebuffer to GEN

tions when 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 p

Re: [Mesa-dev] [PATCH 6/7] i965: ensure execution of fragment shader when fragment shader has atomic buffer access

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

Re: [Mesa-dev] [PATCH 5/7] i965: use _mesa_geometry_width/height/layers/samples for programming geometry of framebuffer to GEN

ngies". -Kevin -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

Re: [Mesa-dev] [PATCH 06/18] intel/common/gen_decoder: make useable from C++ source

Hi, Oh MY! I missed that it was added to the driver (because miraculously the patch applied cleanly anyway). Thanks, I will drop this patch if I make a v3. -Kevin -Original Message- From: Landwerlin, Lionel G Sent: Monday, November 13, 2017 3:45 PM To: Rogovin, Kevin ; mesa-dev

Re: [Mesa-dev] [PATCH 07/18] intel/compiler: fix for memmove argument on annotating error

it crash on before. -Kevin -Original Message- From: Matt Turner [mailto:matts...@gmail.com] Sent: Monday, November 13, 2017 9:02 PM To: Rogovin, Kevin Cc: mesa-dev@lists.freedesktop.org Subject: Re: [Mesa-dev] [PATCH 07/18] intel/compiler: fix for memmove argument on annotating error

Re: [Mesa-dev] [PATCH 08/18] intel/compiler:add function to give option to print offsets into assembly

...@gmail.com] Sent: Monday, November 13, 2017 9:42 PM To: Rogovin, Kevin Cc: mesa-dev@lists.freedesktop.org Subject: Re: [Mesa-dev] [PATCH 08/18] intel/compiler:add function to give option to print offsets into assembly On Mon, Nov 13, 2017 at 5:17 AM, wrote: > From: Kevin Rogovin > > S

Re: [Mesa-dev] [PATCH 10/18] intel/tools/disasm: add gen_disasm_assembly_length function

I need this function in order for the logger to save shader binary to disk. -Kevin -Original Message- From: Matt Turner [mailto:matts...@gmail.com] Sent: Monday, November 13, 2017 9:43 PM To: Rogovin, Kevin Cc: mesa-dev@lists.freedesktop.org Subject: Re: [Mesa-dev] [PATCH 10/18] intel

Re: [Mesa-dev] [PATCH 11/18] intel/tools/disasm: make sure that entire range is disassembled

Your theory makes sense to me too; I suspect that something in the annotation code is the ultimate cause. -Original Message- From: Matt Turner [mailto:matts...@gmail.com] Sent: Monday, November 13, 2017 9:15 PM To: Rogovin, Kevin Cc: mesa-dev@lists.freedesktop.org Subject: Re: [Mesa

Re: [Mesa-dev] [PATCH 18/18] intel/tools: add command line GEN shader disassembler tool

3, 2017 8:09 PM To: Rogovin, Kevin Cc: mesa-dev@lists.freedesktop.org Subject: Re: [Mesa-dev] [PATCH 18/18] intel/tools: add command line GEN shader disassembler tool On Monday, 2017-11-13 15:18:06 +0200, kevin.rogo...@intel.com wrote: > From: Kevin Rogovin > > Signed-off-by: Kevin Rog

Re: [Mesa-dev] [PATCH 07/18] intel/compiler: fix for memmove argument on annotating error

: Matt Turner [mailto:matts...@gmail.com] Sent: Monday, November 13, 2017 11:21 PM To: Rogovin, Kevin 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:12 PM, Rogovin, Kevin wrote: >

[Mesa-dev] Difference between Meson and autotools release builds

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 https

Re: [Mesa-dev] Difference between Meson and autotools release builds

Just to clarify, I do not mean just the defaults, but doing -buildtype release also leaves assert()'s active (atleast on my system setup). -Kevin From: Rogovin, Kevin Sent: Wednesday, November 15, 2017 11:44 AM To: mesa-dev@lists.freedesktop.org Subject: Difference between Meson and auto

Re: [Mesa-dev] Difference between Meson and autotools release builds

Thanks, I missed that; sorry for the mailing list chatter caused by missing the original e-mail on the material. -Kevin -Original Message- From: Eric Engestrom [mailto:eric.engest...@imgtec.com] Sent: Wednesday, November 15, 2017 1:39 PM To: Rogovin, Kevin Cc: mesa-dev

Re: [Mesa-dev] [PATCH 07/18] intel/compiler: fix for memmove argument on annotating error

Thankyou! very much for the patch to the command line disassembler. -Kevin -Original Message- From: Matt Turner [mailto:matts...@gmail.com] Sent: Friday, November 17, 2017 6:52 AM To: Rogovin, Kevin Cc: mesa-dev@lists.freedesktop.org Subject: Re: [Mesa-dev] [PATCH 07/18] intel

Re: [Mesa-dev] [PATCH 0/5] i965: ASTC5x5 workaround

, 2017 7:38 PM To: Rogovin, Kevin Cc: mesa-dev@lists.freedesktop.org Subject: Re: [Mesa-dev] [PATCH 0/5] i965: ASTC5x5 workaround On Fri, Dec 1, 2017 at 12:19 PM, wrote: > From: Kevin Rogovin > > This patch series implements a needed workaround for Gen9 for ASTC5x5 > sampler reads.

Re: [Mesa-dev] [PATCH 0/5] i965: ASTC5x5 workaround

--Original Message- From: Matt Turner [mailto:matts...@gmail.com] Sent: Friday, December 1, 2017 8:25 PM To: Rogovin, Kevin Cc: Ilia Mirkin ; mesa-dev@lists.freedesktop.org Subject: Re: [Mesa-dev] [PATCH 0/5] i965: ASTC5x5 workaround On Fri, Dec 1, 2017 at 10:06 AM, Rogovin, Kevin wrote: > Hi,

Re: [Mesa-dev] [PATCH 0/5] i965: ASTC5x5 workaround

Hi, > 1) do extra tex cache flush when needed and specifically only when needed > 2) resolve surfaces when undesired combination is about to be sampled >Latter case could be addressed also with on-the-fly check in >brw_predraw_resolve_inputs(). There one goes thru all the active textures for >t

  1   2   >