[Mesa-dev] [PATCH] r600g: Avoid setting one gpu register multiple times in a r600_pipe_state

Mathias Fröhlich Mathias.Froehlich at gmx.net
Sun Mar 13 23:45:35 PDT 2011


On Sunday, March 13, 2011 17:34:08 Henri Verbeet wrote:
> Ok, pushed. You had some whitespace issues, I've fixed those, but for
> future reference please note that r600g uses tabs for indentation.
Ok. I hoped that I always did so. The coding stlye configuration for the mesa 
hacking user is tuned for the indentation of the majority of code in mesa 
which does not use tabs. So r600g changes gets usually hand changed tabs.

I had, for a different project/source combination, already some kind of folder 
name matching in my emacs configuration that dynamically switches the coding 
style. But that is somehow complicated to install and making the directory 
matches foolproof is not always simple, so that I only use this kind of lisp 
hackery very seldom.

How do you solve these kind of differences within a single source tree?

By that way, I use currently git format-patch and attach these files.
But the output of format-patch is clearly something that could go directly to 
a mail delivery agent. But since I only use authenticated mail delivery with a 
foreign sendmail/postfix server at gmx, I cannot just use this directly. Is 
there a trick in git, that I can use to make git-format-patch to mail directly 
to smtp.gmx.net for example?

What do you use?

> Thinking about the patch some more though, I wonder if the original
> code wasn't wrong anyway. I think it could cause e.g. Z_EXPORT_ENABLE
> to be incorrectly set when switching from a shader that exports depth
> to one that doesn't.
Ah, that is what you were referring to. I have forgotten about that. Sorry!
The patch was in my tree for ages, so I missed this possibly cleared bit in 
the mail as well as in the commit message.
But yes, since this configures the outputs of a shader that either writes to 
that output or does not write to that output, the result of the command stream 
should either set or clear that bits.
... I should allways immediately write the full comments to the patches.



More information about the mesa-dev mailing list