ChanServ changed the topic of #dri-devel to: <ajax> nothing involved with X should ever be unable to find a bar
rasterman has joined #dri-devel
danvet has quit [Ping timeout: 480 seconds]
tursulin has quit [Read error: Connection reset by peer]
pcercuei_ has quit []
iive has quit []
eukara has quit [Remote host closed the connection]
eukara has joined #dri-devel
maxzor has joined #dri-devel
rasterman has quit [Quit: Gettin' stinky!]
Haaninjo has quit [Quit: Ex-Chat]
maxzor has quit [Remote host closed the connection]
maxzor has joined #dri-devel
JoniSt has quit [Ping timeout: 480 seconds]
heat has quit [Remote host closed the connection]
maxzor has quit [Ping timeout: 480 seconds]
heat has joined #dri-devel
<imirkin>
zmike: maybe wait for comments to be resolved before merging?
<zmike>
imirkin: are they not resolved?
<imirkin>
i left some comments
<imirkin>
the main comment is "this stuff should not be needed and i haven't seen a reasonable explanation as to why it is"
<zmike>
I think I responded to that in one of my first comments in which I said that no other driver has to export vulkan pointsize
<imirkin>
how is that connected?
<imirkin>
to what the state tracker is feeding through
<zmike>
because the purpose of this is to export pointsize so that it can be used by a vulkan driver
<imirkin>
why does st/mesa have to care about any of this?
<zmike>
because st/mesa is the only place this data is available
<imirkin>
which data exactly?
<zmike>
glPointSize data
<imirkin>
you mean the "fixed" point size from the glPointSize() API?
<zmike>
I mean the desktop GL handling
<imirkin>
isn't all that in the rast state?
<zmike>
rast state doesn't tell me whether I'm in an ES context so I can precompile my shaders correctly
<imirkin>
why do you care if it's ES?
<zmike>
as I don't have that state at the necessary time
<imirkin>
you should have rast->point_size_per_vertex
<imirkin>
and rast->point_size
<zmike>
except that rast=null in this scenario
<zmike>
so that's not viable
<imirkin>
if the former is set, then you use from shader. if the latter is set, then you load that value from the uniform
<imirkin>
if rast = null that means you're very early in context creation. you can assume whatever, and it'll get set to something later
columbarius has joined #dri-devel
<zmike>
rast=null means I can't use the rasterizer state because it's a precompile
<imirkin>
other stuff can change too
<imirkin>
so you can just pick whatever value you want
<imirkin>
you can't guarantee that you'll guess right anyways
<zmike>
I can't guarantee it, but the st case is much more accurate than a completely random guess
<imirkin>
if that's _really_ your problem, then you can make st set the rast earlier
<imirkin>
so that it _is_ set for your situation
Bennett has joined #dri-devel
co1umbarius has quit [Ping timeout: 480 seconds]
<zmike>
no, I can't, because gallium doesn't guarantee atom state ordering, so I can never, ever use the rasterizer state during precompile
<imirkin>
you could just set it right at context creation
<zmike>
that's irrelevant since there's other state trackers which might not
<zmike>
I'm not sure why this is such an issue for you now when that pass has existed for years and the only thing I'm doing is fixing it to pass CTS
<imirkin>
because you're adding a lot of, imo, very confused logic
<imirkin>
which doesn't make a whole lot of sense to me
<imirkin>
when it's off in some random driver i'm not involved in, i don't care too much
<imirkin>
when it's in shared code that i'm involved in maintaining, i care a lot more
<imirkin>
from what you said now, you're adding these oodles of logic to avoid a if (rast) check somewhere and the occasion extra recompile if you guess wrong
<imirkin>
which would fix the CTS test equally well, from what i can gather
<zmike>
no, now you're conflating my statements about using the rasterizer state for precompile with the ability to pass cts
<imirkin>
ah ok
<imirkin>
so what's the bit that makes it pass cts then?
<zmike>
all of it?
<imirkin>
sigh
<zmike>
the fact that it also works for precompile is an added bonus
<imirkin>
ok. so what's an example of a problem case, and how do your changes make it better?
<zmike>
they're in the commit logs
<imirkin>
i looked at the commit logs for the st/mesa changes
<imirkin>
i was unable to find that info there
<imirkin>
(i didn't look at the other changes)
<imirkin>
i don't have a clear picture of what the problem is, nor how the changes "fix" anything
<imirkin>
shouldn't that be backwards? i.e. always-false for ES2? (since it's !PointSizeEnabled for desktop GL)
<zmike>
no
<imirkin>
(although i haven't looked precisely at what export_point_size does. probably should.)
<zmike>
in the existing code the key means whether the shader needs to export a pointsize value
<zmike>
not whether to run the pass
<imirkin>
right ... let me read a bit of code and come back
<zmike>
I didn't realize you were still in the position of strongly objecting when I happened to arrive home and thought i could snag a few minutes on marge during the downtime at the end of my three day weekend
<zmike>
if that's still your position, I'll cancel and we can continue to discuss this
<zmike>
but I'm not going to spend more time on it today one way or another
<imirkin>
reverts work just as well
<zmike>
the point (no pun intended) was to get the tests passing now and then do cleanups and prettifications later once CI is capable of catching regressions
<imirkin>
well, i guess i have a slightly different philosophy, which is to make sure that upstream code is as good as possible, and all making sense. i believe this makes it easier to maintain.
<zmike>
I think the only difference is in timetable
<imirkin>
hm, interesitng. if export_point_size is set, it still tries to avoid clobbering existing point size export.
<imirkin>
i wonder if that's not working for some reason?
<zmike>
it's working exactly as I intended it to
<zmike>
when my understanding of pointsize was less comprehensive
<imirkin>
or is your goal to avoid having the point size be set in the shader in the first place if the "source" shader doesn't set it?
<zmike>
the goal at the time was to have pointsize be exported
<imirkin>
right
<imirkin>
(seems to do that)
<imirkin>
what's the goal now?
<zmike>
to do it correctly
<imirkin>
how is the existing thing incorrect?
* airlied
did try removing that check, some tests seemed to pass
<zmike>
because glPointSize isn't handled
<zmike>
possibly other things? as I said, this is the end of a long weekend for me so what I have is the remnants of a real person's brain right now
<zmike>
if you still object, feel free to unassign, and in any case I'll follow up in the near future
<imirkin>
ok. then maybe come back to it and clean up the explanation when you're functioning better then?
<imirkin>
ok
<imirkin>
i'll deassign for now
<imirkin>
and leave a comment
<imirkin>
with some potential avenues to check out
<imirkin>
(the comment will take a little bit to write up, but i'll do it soon)
camus1 has quit [Remote host closed the connection]
camus has joined #dri-devel
mbrost has quit [Ping timeout: 480 seconds]
Bennett has quit [Remote host closed the connection]
macromorgan is now known as Guest125
Guest125 has quit [Read error: Connection reset by peer]
macromorgan has joined #dri-devel
sdutt has quit [Ping timeout: 480 seconds]
mclasen has quit []
mclasen has joined #dri-devel
off^ has quit [Ping timeout: 480 seconds]
mclasen has quit [Ping timeout: 480 seconds]
aruna has joined #dri-devel
shankaru has joined #dri-devel
aruna has quit []
off^ has joined #dri-devel
The_Company has quit []
yoslin has quit [Remote host closed the connection]
yoslin has joined #dri-devel
Daanct12 has quit [Quit: Quitting]
aravind has joined #dri-devel
Danct12 has joined #dri-devel
Duke`` has joined #dri-devel
lemonzest has joined #dri-devel
heat has quit [Ping timeout: 480 seconds]
kts has joined #dri-devel
itoral has joined #dri-devel
mszyprow has joined #dri-devel
macromorgan is now known as Guest145
Guest145 has quit [Read error: Connection reset by peer]
macromorgan has joined #dri-devel
mlankhorst has joined #dri-devel
gnuiyl has joined #dri-devel
danvet has joined #dri-devel
cafuffu has joined #dri-devel
frieder has joined #dri-devel
frieder has quit []
frieder has joined #dri-devel
Duke`` has quit [Ping timeout: 480 seconds]
alanc has quit [Remote host closed the connection]
alanc has joined #dri-devel
gouchi has joined #dri-devel
gouchi has quit [Remote host closed the connection]
maxzor has joined #dri-devel
MajorBiscuit has joined #dri-devel
pnowack has joined #dri-devel
tursulin has joined #dri-devel
maxzor has quit [Ping timeout: 480 seconds]
pq has quit [Ping timeout: 480 seconds]
pq has joined #dri-devel
jewins has quit [Ping timeout: 480 seconds]
kchibisov has joined #dri-devel
flto has quit [Remote host closed the connection]
flto has joined #dri-devel
kts has quit [Quit: Konversation terminated!]
maxzor has joined #dri-devel
kts has joined #dri-devel
JohnnyonFlame has quit [Ping timeout: 480 seconds]
kts has quit []
pcercuei has joined #dri-devel
maxzor has quit [Remote host closed the connection]
maxzor has joined #dri-devel
maxzor has quit [Remote host closed the connection]
thellstrom has joined #dri-devel
JohnnyonFlame has joined #dri-devel
lkw has joined #dri-devel
kts has joined #dri-devel
lemonzest has quit [Quit: WeeChat 3.4]
mvlad has joined #dri-devel
cafuffu has quit [Ping timeout: 480 seconds]
lkw_ has joined #dri-devel
lkw has quit [Ping timeout: 480 seconds]
maxzor has joined #dri-devel
itoral has quit [Remote host closed the connection]
itoral has joined #dri-devel
devilhorns has joined #dri-devel
itoral has quit [Remote host closed the connection]
itoral has joined #dri-devel
mclasen has joined #dri-devel
itoral has quit [Remote host closed the connection]
itoral has joined #dri-devel
itoral has quit [Remote host closed the connection]
itoral has joined #dri-devel
ahajda_ has joined #dri-devel
itoral has quit [Remote host closed the connection]
itoral has joined #dri-devel
hansg has joined #dri-devel
itoral has quit [Remote host closed the connection]
itoral has joined #dri-devel
itoral has quit [Remote host closed the connection]
itoral has joined #dri-devel
itoral has quit [Remote host closed the connection]
itoral has joined #dri-devel
itoral has quit [Remote host closed the connection]
itoral has joined #dri-devel
itoral has quit [Remote host closed the connection]
itoral has joined #dri-devel
camus has quit [Remote host closed the connection]
camus has joined #dri-devel
itoral has quit [Remote host closed the connection]
itoral has joined #dri-devel
gawin has joined #dri-devel
maxzor has quit [Remote host closed the connection]
rasterman has joined #dri-devel
itoral has quit [Remote host closed the connection]
gawin has quit [Ping timeout: 480 seconds]
JoniSt has joined #dri-devel
kts has quit [Quit: Konversation terminated!]
<JoniSt>
Well, I understand now why Vulkan did away with all these implicit synchronization guarantees that OpenGL had... Writing GL drivers seems to be a very special kind of hell...
lemonzest has joined #dri-devel
<HdkR>
Don't worry, now every application developer can experience that hell by writing a vulkan app
<JoniSt>
True - but making a single application sync correctly seems to be less of a hell to me than trying to make synchronization code that works correctly with ALL applications :P
Guest181 has quit [Read error: Connection reset by peer]
macromorgan has joined #dri-devel
dllud has joined #dri-devel
sdutt has joined #dri-devel
sdutt has quit []
sdutt has joined #dri-devel
gawin has joined #dri-devel
nadrian has joined #dri-devel
Company has joined #dri-devel
macromorgan is now known as Guest185
Guest185 has quit [Read error: Connection reset by peer]
macromorgan has joined #dri-devel
nadrian has quit []
nadrian has joined #dri-devel
alyssa has joined #dri-devel
<alyssa>
Why do non-software/layered/non-DRI drivers handle PIPE_BIND_DISPLAY_TARGET?
<alyssa>
It looks like it's named confusingly and normal hardware+DRM drivers should only ever see SCANOUT and SHARED?
slattann has left #dri-devel [#dri-devel]
slattann has joined #dri-devel
macromorgan has quit [Read error: Connection reset by peer]
macromorgan_ has joined #dri-devel
<daniels>
they're not _quite_ the same; DISPLAY_TARGET means that it's going to an external consumer like winsys, SCANOUT means that it's specifically going to be displayed by non-GPU hardware so please be gentle, and SHARED just means that someone else can access it
<alyssa>
I'm not seeing the distinction (or where it's documented..)
<alyssa>
it would /appear/ from the docs it's about pipe_screen::flush_front_buffer
<alyssa>
and any driver that doesn't implement flush_frontbuffer doesn't need to handle DISPLAY_TARGET..
<alyssa>
Kayden: speaking of, why does iris nop out flush_frontbuffer?
<alyssa>
(crocus too)
<alyssa>
and tegra passes it through but nouveau doesn't implement it, so that's almost certainly an untested broken code path
macromorgan_ has quit [Read error: Connection reset by peer]
<alyssa>
i915 has a particularly creative way of not implementing it
<alyssa>
(i915g)
macromorgan has joined #dri-devel
<alyssa>
the other drivers implementing it are: softpipe, llvmpipe, virgl, zink, d3d12, asahi
<alyssa>
(aka the drivers that go through the software WSI paths)
<alyssa>
(asahi does because there is no way I am implementing macOS WSI into Mesa when the driver is only meant to ship on Linux)
<danvet>
demarchi, imo once you pile up fixup patches you have too many conflicts
<danvet>
and should backmerge asap
<danvet>
or whatever it is
<danvet>
will backmerging not fix things up?
<demarchi>
another issue is that... if we fixup the merge itself, it gets lost and we have to do a fixup later
<danvet>
like I can throw PR into drm-next, but backmerging aint on me
<danvet>
test merge in a clean tree before you send the pr
<demarchi>
I agree... that's why I said first issue is "the trees diverged"
<demarchi>
danvet: I wanted a --local to dim, so it does everything locally, before pushing anything. I don't think we have something like that, do we?
<danvet>
-d
<danvet>
for dry run
<demarchi>
danvet: I fixed up the merge commit only to find out later the merge fixes got lost and I needed to fix things up again,
<danvet>
demarchi, yeah that can happen with rerere
<danvet>
which is why you need to run rebuild-tip and check it worked
<demarchi>
but rebuild-tip means the branch was already pushed
<demarchi>
humn... maybe I missed the -d, but when I looked it didn't use the local changes on the barnch I wanted
<demarchi>
i.e. cat /tmp/patches.mbx | dim am
<demarchi>
dim rebuild-tip will get the remote branch, not the local ref
agd5f_ has joined #dri-devel
shankaru has quit [Quit: Leaving.]
agd5f_ has quit []
agd5f_ has joined #dri-devel
shsharma has joined #dri-devel
maxzor has joined #dri-devel
CATS has joined #dri-devel
agd5f_ has quit []
agd5f has quit [Ping timeout: 480 seconds]
agd5f has joined #dri-devel
mclasen has quit [Remote host closed the connection]
tobiasjakobi has joined #dri-devel
<ajax>
eric_engestrom: you're the 21.3 boss, any objections to landing !10557 ?
rgallaispou has quit [Ping timeout: 480 seconds]
<cheako>
I'm proud of the work done on https://gitlab.com/cheako/vk-layer-cache in it's current state this is a powerful tool and I feel should fill novel use cases.
<cheako>
I'm going to add graphics pipeline support in the coming days, it's cumbersome. Afterwards it'll be feature complete for my purpose.
<cheako>
It is missing polish and a readme. It has been suggested that a vulkan chanel would be a better place to get assistance, are there any recommendations?
gouchi has joined #dri-devel
mclasen has joined #dri-devel
MajorBiscuit has quit [Ping timeout: 480 seconds]
ybogdano has quit [Ping timeout: 480 seconds]
<agd5f>
I presume you still need fdo ssh access for releasing X stuff for dealing with tarballs?
<Kayden>
alyssa: I'm pretty sure iris_flush_frontbuffer() exists because I copied it from noop_flush_frontbuffer()
<Kayden>
alyssa: and never thought of any code to put there
<Kayden>
it's entirely possible that it can/should be deleted :)
thellstrom1 has joined #dri-devel
thellstrom has quit [Remote host closed the connection]
<alyssa>
Kayden: fair enough!
shsharma has quit []
shsharma has joined #dri-devel
thellstrom1 has quit []
gawin has joined #dri-devel
shsharma is now known as shashanks
<shashanks>
Hello @daniels
<daniels>
shashanks: hi there
<shashanks>
I am trying to push the amdgpu-ddx tarballs for the next release
<shashanks>
but it seems like I dont have permissions to annarchy.freedesktop.org
<shashanks>
can you please suggest how can I get that ?
<daniels>
agd5f: ^ is this ok
<shashanks>
(using the relese.sh script)
<agd5f>
daniels, yes, please
<airlied>
alyssa: and crocus is just c'n'p from iris
<daniels>
agd5f: thanks
<daniels>
shashanks: added you now, please wait 10min before trying again
<shashanks>
thank you
<agd5f>
daniels, thanks
<daniels>
np
tobiasjakobi has quit []
<alyssa>
airlied: naturally
ybogdano has joined #dri-devel
devilhorns has quit []
whald has quit [Remote host closed the connection]
tzimmermann has joined #dri-devel
mbrost has joined #dri-devel
<tzimmermann>
mlankhorst, mripard, danvet, have there been any PRs for drm-misc-next during february?
<Kayden>
screenshots of PIGLIT_PLATFORM=gbm tests in konsole from git
camus has quit [Read error: Connection reset by peer]
<Kayden>
jljusten: ^^^
<Kayden>
probably need to add code to detect whether the terminal supports it and the number of color registers it has available
<Kayden>
which you can do via CSI sequences, but I'm unsure how to send those and read responses
gawin has joined #dri-devel
<alyssa>
Kayden: this is terrifying
mlankhorst has quit [Ping timeout: 480 seconds]
<Kayden>
:D
<jljusten>
Kayden: nice. :) too bad last I checked the tmux devs seemed opposed to supporting this and related pixel in console features. :/
<bnieuwenhuizen>
good enough argument to switch to screen? (not that I have a clue if they support it)
<Kayden>
there is a screen branch that supports it, and some ways of bypassing it, I guess
<Kayden>
it's actually part of the DEC VT340 from 1987, so it's not like we're inventing things here, heheh
<eric_engestrom>
ajax: !10557 still looks good to me, and yeah feel free to merge it into 21.3; I've just changed the target branch to staging/21.3 though, as 21.3 is for released commits only, and staging/21.3 is where dev (ie. mostly cherry-picks from main) happens
<ajax>
eric_engestrom: ah, gotcha. thanks, will merge shortly
fxkamd has quit [Remote host closed the connection]
fxkamd has joined #dri-devel
* ajax
pondering a sixel wsi
<ajax>
obviously you need to be able to play doom with this
<eric_engestrom>
actually I forgot to mention the main point: staging/21.3 is a rebasing branch, as sometimes backports introduce issues and need to be modified (or sometimes removed); once a release is done, 21.3 is updated to point to the current state of staging/21.3, and all of that become hard history, and only stuff on top gets to be rebased
<jljusten>
Kayden: I guess there's a tmux fork that supports it. https://github.com/csdvrx/sixel-tmux But, I've seen related tmux issues/PR's closed saying they don't plan to support it. :(