[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
Hi,
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.
Thanks!
Mathias
More information about the mesa-dev
mailing list