ChanServ changed the topic of #dri-devel to: <ajax> nothing involved with X should ever be unable to find a bar
<daniels>
thanks!
<zmike>
jekstrand: bad news: ssbos are hard
icecream95 has quit [Ping timeout: 480 seconds]
columbarius has quit [Ping timeout: 480 seconds]
toolchains has joined #dri-devel
ella-0_ has joined #dri-devel
ella-0 has quit [Read error: Connection reset by peer]
toolchains has quit [Ping timeout: 480 seconds]
ybogdano has quit [Ping timeout: 480 seconds]
toolchains has joined #dri-devel
camus has joined #dri-devel
toolchains has quit [Ping timeout: 480 seconds]
camus1 has joined #dri-devel
heat has quit [Ping timeout: 480 seconds]
camus has quit [Ping timeout: 480 seconds]
toolchains has joined #dri-devel
toolchains has quit [Ping timeout: 480 seconds]
mbrost_ has joined #dri-devel
mbrost__ has quit [Ping timeout: 480 seconds]
Daanct12 has joined #dri-devel
anujp_ has quit [Ping timeout: 480 seconds]
bmodem has joined #dri-devel
ngcortes has joined #dri-devel
camus1 has quit []
bmodem has quit [Ping timeout: 480 seconds]
anujp_ has joined #dri-devel
bmodem has joined #dri-devel
toolchains has joined #dri-devel
bmodem has quit [Remote host closed the connection]
<jekstrand>
zmike: Yes, they are. I'll look tomorrow.
toolchains has quit [Ping timeout: 480 seconds]
<zmike>
🙏💪🙏
mbrost_ has quit [Ping timeout: 480 seconds]
mbrost_ has joined #dri-devel
toolchains has joined #dri-devel
toolchains has quit [Ping timeout: 480 seconds]
Duke`` has joined #dri-devel
idr has quit [Quit: Leaving]
mbrost_ has quit [Ping timeout: 480 seconds]
Daanct12 has quit [Remote host closed the connection]
Daanct12 has joined #dri-devel
mclasen_ has quit []
mclasen has joined #dri-devel
bmodem has joined #dri-devel
slattann has joined #dri-devel
saurabhg has joined #dri-devel
toolchains has joined #dri-devel
mclasen has quit []
mclasen has joined #dri-devel
toolchai_ has joined #dri-devel
wens has quit [Read error: Connection reset by peer]
mbrost_ has joined #dri-devel
wens has joined #dri-devel
toolchains has quit [Ping timeout: 480 seconds]
aravind has joined #dri-devel
Daaanct12 has joined #dri-devel
mclasen has quit [Ping timeout: 480 seconds]
Daanct12 has quit [Read error: Connection reset by peer]
Daaanct12 is now known as Daanct12
lemonzest has joined #dri-devel
saurabhg has quit [Ping timeout: 480 seconds]
sdutt has quit [Read error: Connection reset by peer]
Duke`` has quit [Read error: Connection reset by peer]
ngcortes has quit [Remote host closed the connection]
tobiasjakobi has joined #dri-devel
tobiasjakobi has quit [Remote host closed the connection]
aravind has quit [Ping timeout: 480 seconds]
tzimmermann_ has quit []
tzimmermann has joined #dri-devel
toolchai_ has quit []
toolchains has joined #dri-devel
itoral has joined #dri-devel
Company has quit [Quit: Leaving]
danvet has joined #dri-devel
toolchains has quit [Remote host closed the connection]
toolchains has joined #dri-devel
saurabhg has joined #dri-devel
toolchains has quit [Ping timeout: 480 seconds]
bmodem has quit [Ping timeout: 480 seconds]
bmodem has joined #dri-devel
alanc has quit [Remote host closed the connection]
alanc has joined #dri-devel
saurabhg has quit [Remote host closed the connection]
saurabhg has joined #dri-devel
toolchains has joined #dri-devel
toolchains has quit [Ping timeout: 480 seconds]
mbrost__ has joined #dri-devel
tursulin has joined #dri-devel
mbrost__ has quit []
mbrost has joined #dri-devel
bmodem has quit [Ping timeout: 480 seconds]
bmodem has joined #dri-devel
mbrost_ has quit [Ping timeout: 480 seconds]
wv has joined #dri-devel
jkrzyszt has joined #dri-devel
MajorBiscuit has joined #dri-devel
wv has quit []
wv has joined #dri-devel
wv has quit []
wvanhauwaert has joined #dri-devel
toolchains has joined #dri-devel
rasterman has joined #dri-devel
ahajda has joined #dri-devel
imre_ has quit []
imre has joined #dri-devel
toolchains has quit [Ping timeout: 480 seconds]
nvishwa1 has quit [Ping timeout: 480 seconds]
toolchains has joined #dri-devel
<pq>
danvet, re: virtual cursor; I'm not sure yet, depends on what zackr says next.
<MrCooper>
zmike daniels: re https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/16863 , disabling *all* unit tests just because some of them time out sometimes (which might indicate something regressed, which is kind of the point of running tests) seems like the very definition of "too big a hammer"... Is someone working on re-enabling at least the non-problematic tests?
toolchains has quit [Ping timeout: 480 seconds]
chaim has joined #dri-devel
lynxeye has joined #dri-devel
rasterman has quit [Quit: Gettin' stinky!]
toolchains has joined #dri-devel
jimjams has quit [Quit: Connection closed for inactivity]
MrCooper has quit [Remote host closed the connection]
toolchains has quit [Ping timeout: 480 seconds]
rsalvaterra has quit [Quit: No Ping reply in 180 seconds.]
rsalvaterra has joined #dri-devel
rsalvaterra has quit []
rsalvaterra has joined #dri-devel
rsalvaterra has quit []
rsalvaterra has joined #dri-devel
pcercuei has joined #dri-devel
pjakobsson has quit [Ping timeout: 480 seconds]
MajorBiscuit has quit [Ping timeout: 480 seconds]
mbrost has quit [Ping timeout: 480 seconds]
apinheiro has joined #dri-devel
MajorBiscuit has joined #dri-devel
saurabh_1 has joined #dri-devel
MrCooper has joined #dri-devel
marex has joined #dri-devel
toolchains has joined #dri-devel
soreau has quit [Read error: Connection reset by peer]
soreau has joined #dri-devel
saurabhg has quit [Ping timeout: 480 seconds]
toolchains has quit [Ping timeout: 480 seconds]
Thaodan is now known as foobar
foobar is now known as Guest1642
Guest1642 has quit []
Thaodan has joined #dri-devel
MajorBiscuit has quit [Ping timeout: 480 seconds]
MajorBiscuit has joined #dri-devel
bmodem has quit [Ping timeout: 480 seconds]
MajorBiscuit has quit [Ping timeout: 480 seconds]
saurabh_1 has quit [Ping timeout: 480 seconds]
mclasen has joined #dri-devel
bmodem has joined #dri-devel
MajorBiscuit has joined #dri-devel
bmodem has quit [Ping timeout: 480 seconds]
heat has joined #dri-devel
rasterman has joined #dri-devel
toolchains has joined #dri-devel
elongbug has joined #dri-devel
toolchains has quit [Read error: Connection reset by peer]
toolchai_ has joined #dri-devel
toolchains has joined #dri-devel
toolcha__ has joined #dri-devel
MajorBiscuit has quit [Ping timeout: 480 seconds]
Daanct12 has quit [Quit: Leaving]
toolchai_ has quit [Ping timeout: 480 seconds]
MajorBiscuit has joined #dri-devel
toolchains has quit [Ping timeout: 480 seconds]
pjakobsson has joined #dri-devel
Akari has quit [Remote host closed the connection]
Akari has joined #dri-devel
saurabhg has joined #dri-devel
MajorBiscuit has quit [Ping timeout: 480 seconds]
pjakobsson_ has joined #dri-devel
JohnnyonFlame has joined #dri-devel
pjakobsson has quit [Ping timeout: 480 seconds]
wvanhauwaert has quit [Ping timeout: 480 seconds]
saurabhg has quit [Ping timeout: 480 seconds]
wvanhauwaert has joined #dri-devel
saurabhg has joined #dri-devel
toolcha__ has quit [Remote host closed the connection]
toolchains has joined #dri-devel
toolchains has quit [Remote host closed the connection]
toolchains has joined #dri-devel
toolchains has quit [Remote host closed the connection]
wv has joined #dri-devel
mclasen has quit [Ping timeout: 480 seconds]
mi6x3m has joined #dri-devel
mi6x3m has quit []
wvanhauwaert has quit [Ping timeout: 480 seconds]
mclasen has joined #dri-devel
<tzimmermann>
javierm, i looked at the sysfb patchset, but don't have more to add than the reply to patch 5
ppascher has joined #dri-devel
ppascher has quit []
gawin has joined #dri-devel
itoral has quit [Remote host closed the connection]
ppascher has joined #dri-devel
npnell has joined #dri-devel
MajorBiscuit has joined #dri-devel
aravind has joined #dri-devel
aravind has quit []
aravind has joined #dri-devel
Company has joined #dri-devel
npnell has quit []
<javierm>
tzimmermann: thanks a lot. I'll drop patch 5 from the set now and post as a follow-up a different version doing what you suggested
<tzimmermann>
ok
<javierm>
tzimmermann: I know remember that sravn_ suggested in v5 to just use EXPORT_SYMBOL_NS_GPL() and make the symbol only exported to dcon
<javierm>
since we were dropping the whole set I didn't make that change and forgot when posted v6
<javierm>
tzimmermann: I'll do what you suggested but also what sravn_ mentioned to export fb_info_get_by_index(), instead of the ifdefery
<javierm>
danvet: do you want me to push the rest of the patches in that series? ^
sul has joined #dri-devel
<danvet>
javierm, yeah if you're up for respinning them sure
sul has quit []
sul has joined #dri-devel
<javierm>
danvet: yes, I'll just cherry-pick 1-4 and drop 5 now. Then work on what they suggested as a followup
saurabhg has quit [Ping timeout: 480 seconds]
toolchains has joined #dri-devel
wv has quit []
wvanhauwaert has joined #dri-devel
toolchains has quit [Ping timeout: 480 seconds]
aravind has quit [Remote host closed the connection]
aravind has joined #dri-devel
apinheiro has quit [Ping timeout: 480 seconds]
slattann has quit [Quit: Leaving.]
sdutt has joined #dri-devel
jagan_ has joined #dri-devel
sul has quit []
sul has joined #dri-devel
Peste_Bubonica has joined #dri-devel
devilhorns has joined #dri-devel
saurabhg has joined #dri-devel
MrCooper has quit [Quit: Leaving]
jagan_ has quit [Remote host closed the connection]
MrCooper has joined #dri-devel
saurabhg has quit [Ping timeout: 480 seconds]
sul has quit []
<Company>
Why is F36 Mesa complaining at me on stderr all the time?
<javierm>
JosExpsito[m]: I think would be good if you can reference your patch too and coordinate to have some consistency across drm (i.e: subdir name for tests, naming convention for test suites, etc)
ybogdano has joined #dri-devel
idr has joined #dri-devel
<mripard>
javierm: wow, that's awesome
<javierm>
mripard: it is indeed
rsalvaterra_ has joined #dri-devel
rsalvaterra is now known as Guest1661
rsalvaterra_ is now known as rsalvaterra
nvishwa1_ has joined #dri-devel
Guest1662 has quit [Ping timeout: 480 seconds]
ybogdano has quit [Ping timeout: 480 seconds]
Duke`` has joined #dri-devel
nvishwa1 has quit [Ping timeout: 480 seconds]
ybogdano has joined #dri-devel
jkrzyszt has quit [Ping timeout: 480 seconds]
MajorBiscuit has quit [Ping timeout: 480 seconds]
<MrCooper>
mdnavare vsyrjala: does toggling the VRR_ENABLED property really require a modeset with Intel HW? (It doesn't with amdgpu)
lynxeye has quit [Quit: Leaving.]
sravn_ is now known as sravn
<sravn>
javierm: I think it was Geert that suggest to use EXPORT_SYMBOL_NS_GPL(), may take was to drop the export and mark dcon BROKEN to avoid any changes in core code to satisfy staging drivers. But the NS_GPL() works for me too and let the dcon driver continue to work in theory (dunno if it works today or not, it does not see any updates last I looked)
alyssa has joined #dri-devel
alyssa has left #dri-devel [#dri-devel]
alyssa has joined #dri-devel
<alyssa>
AFAIU, Vulkan drivers aren't supposed to do shader variants -- queueing a draw shouldn't result in a compile
<alyssa>
what about transfers?
<alyssa>
is it acceptable for vkCmdCopyImage to result in a shader compile, for example?
<alyssa>
(as opposed to precompiling every possible meta shader ahead-of-time)
<alyssa>
I *think* anv does that
<anholt>
I think I'd forgive you for meta shaders that are super short and quick to compile, but tu at least precompiles all our meta shaders.
<alyssa>
ok
<alyssa>
panvk is compiling 400+ meta shaders on startup
<alyssa>
i'm thinking that's .. maybe not great ..
<anholt>
eh, if you're packing them all in one BO at least that sounds not too bad.
<alyssa>
(Especially given they're going through nir_builder + NIR optimizer + backend optimizer)
<anholt>
(one BO because we had trouble in turnip where submits got slow in the kernel because every pipeline was in its own bo)
<alyssa>
sure
<alyssa>
i'm new to vulkan
mbrost_ has joined #dri-devel
<alyssa>
not yet liking it too much ...
<LaserEyess>
as of 22.1, are there any dire consequences of compiling mesa with no openGL support besides zink?
<LaserEyess>
or is it at the point of "just try it and see what breaks"
<alyssa>
brave
<idr>
You won't be able to run glxgears.
<idr>
That's pretty dire.
<idr>
;)
<anarsoul>
alyssa: isn't disk cache supposed to help?
mbrost has quit [Ping timeout: 480 seconds]
<alyssa>
anarsoul: err.. yeah, I guess so
<alyssa>
like I said. new to VK.
<LaserEyess>
idr: as long as it doesn't crash my whole OS I can deal with that
<idr>
jenatali: If nothing else, I can peel a few commits out to land sooner.
<alyssa>
that implementation is closer to csel than cmp
<jenatali>
Only if it languishes. I'm not in a rush, I just don't want them to disappear
<idr>
The microsoft/compiler: commit and the first 3 should be pretty safe.
<alyssa>
In fact, that MUX can be scheduled as a MUX or as a CSEL, which means it's easier to schedule (2x throughput in a sequence of entirely i2b32)
<alyssa>
whereas `x != 0` will select an ICMP, which can only be scheduled to a single unit on Bifrost
<alyssa>
so all else being equal, I'd expect cycle count to be hurt
<idr>
Hm...
<alyssa>
but wait, you say, what if the app writes "x != 0" opencoded? shouldn't we optimize that to MUX/CSEL instead of ICMP?
<idr>
alyssa: The broadcom compiler had a similar optimization for i2b, but removing it actually helped. I had a patch for bcm that implemented `x != 0` (and also `x == 0`) in the same fashion as the i2b optimization.
<alyssa>
on Valhall, MUX is slowed down so we always replace it with CSEL
<alyssa>
CSEL and ICMP are both on the same unit on Valhall
<alyssa>
so in theory should be identical scheduling
<idr>
I wasn't paying enough attention when I made the bifrost change, or I would had tried the optimization there too.
Peste_Bubonica has joined #dri-devel
<alyssa>
booleans are a mess of nonorthogonal instructions on bifrost/valhall
<alyssa>
there are 3* instructions
<alyssa>
1. 4-source CSEL, compare the first two args and select from the second two
<idr>
Yeah howdy they are on many platforms.
<idr>
It's a huge mess of tradeoffs on Intel too.
<alyssa>
2. 3-source MUX, compare the last to 0 (of various data types) and select from the first two
<alyssa>
3. 2-source CMP, do a comparison and output either 0/~0, 0/1, or 0/1.0 depending on result_type
<jekstrand>
idr: Why didn't you delete the opcode?
<alyssa>
To further complicate, Bifrost is a 32-bit ISA that allows packed i16vec2 and i8vec4
<idr>
jekstrand: I really, really want to, but...
mclasen has quit [Ping timeout: 480 seconds]
<idr>
...other places use nir_type_conversion_op.
<alyssa>
So there are actually 8 boolean datatypes the hw can produce
<jekstrand>
idr: Ugh...
<idr>
I think it won't be too much work to change the way that is used.
<idr>
I have a similar series for f2b.
<alyssa>
I've tried to attack that from a few angles, in the end my solution is:
<idr>
I will probably combine the f2b series with "delete ?2b opcodes." We'll see.
<alyssa>
1. Use lower_bool_to_bitsize. This isn't a perfect match for the hw but usually picks the right size.
<alyssa>
2. Always map to 0/~0 booleans, to match the NIR semantic with the sized booleans
<alyssa>
3. Map all the various boolean things to MUX as a canonical form for the optimizer and scheduler.
<alyssa>
4. Peephole optimize CMP+MUX to CMP-with-result_type
<alyssa>
(5. Peephole optimize CMP+MUX to 4-source CSEL although that caused shaderdb regressions when I tried it)
ybogdano has quit [Ping timeout: 480 seconds]
<alyssa>
This isn't well-motivated theoretically, but in practice it works pretty well
Akari has quit [Read error: Connection reset by peer]
<gawin>
hello again, I don't have experience with Khronos group, but do you think it'd be viable option to propose dynamic loops for fragment shaders as optional extension for gles 2.0? (if this makes sense)
Akari has joined #dri-devel
<alyssa>
that's core gles2.
<alyssa>
optional but core.
<gawin>
I think then we would be able to fallback to software rendering earlier without need to analyze shader on semantic level
<Venemo>
anholt: ping. Sorry but could we discuss this CI thing? Your comment on gitlab did not answer my questions, so you copy-pasted the same comment again? Can we talk about it in a civilised manner please?
<airlied>
dcbaker, or anyone: any examples of a custom meson rule that takes a bunch of files and generates the same number of output files based on them?
mclasen has joined #dri-devel
<gawin>
alyssa: "recent" software assumes that everything has dynamic loops .-.
<dcbaker>
airlied: Like It takes N inputs and produces N outputs?
<airlied>
dcbaker: yes
<airlied>
and I assume then I have to have something dep on the N outputs
<idr>
gawin: I suspect most recent software uses GLES2 but basically assumes "nearly" GLES3 hardware.
<airlied>
if I can do that without explicitly listing them all in two places
<anholt>
Venemo: sure. I'm really unclear on what's not translating here
<idr>
gawin: Because the GLES3 deployment on most platforms was not great. :(
<anholt>
we have a variety of test jobs that can't be enabled by default because they're unstable, but are still useful to devs of a specific driver.
<dcbaker>
airlied: if you just want a dep on all the outputs, make a dep on the custom_target.
<alyssa>
"
<anholt>
or because they're full runs that should be run only infrequently because they're too expensive.
<alyssa>
What do you mean by staleness?"
<dcbaker>
I’m on my phone, but I’ll be back on my computer in a few
<airlied>
dcbaker: no hurry I'm just looking around now anyways
<anholt>
so, when you want to run CI, you run the container jobs which run all the enabled-by-default test jobs that give good results and don't lock up CI for other people.
<Venemo>
anholt: I assumed that I have a better chance of catching regressions if I run non-default CI jobs
<anholt>
the not-enabled-by-default test jobs often have stale results, because they aren't being run regularly and things regress. or, like gc2000, the flakiness hasn't been categorized and you'll get some collection of fails that were really flaky results but you as the reader don't know.
<Venemo>
For example, Valve CI is not enabled by default but is invaluable for us
<anholt>
the problem with running non-default CI jobs is that you need the familiarity with that specific job to interpret results, due to stale results, flaky results, unstable issues with the driver ("did my change make this board not boot? whaaat?)
<Venemo>
OK. I just wanted to avoid regressing your stuff
<Venemo>
Did not realize I shouldn't do that
<Venemo>
That being said, I really am a bit afraid whether the depth related failure is caused by my commit or not
<Venemo>
If not - great!
<gawin>
imho also injecting fixes into foreign code would be easier, check if advertised opengl es is version X or higher and driver doesn't advertised extension, then use fix
<anholt>
I do really wish valve would get their runners enabled by default. they seem pretty critical for radv.
<anholt>
(and it seems like their results rot periodically since they're not on by default!)
<anholt>
Venemo: "depth related failure"?
<airlied>
dcbaker: found an example in radv
<Venemo>
anholt: I think mupuf is doing the best he can, with the Valve CI. it is updated quite frequently.
<Venemo>
anholt: we are not allowed to enable it by default because its runtime is too long
<dcbaker>
airlied: cool
<airlied>
except mine blows up meson :-P
<anholt>
Venemo: so, that's the difference have between like a618-vk and a618-vk-full: a618-vk is a 1/3 run that we can do in the normal-MR timeframe, and a618-vk-full is what a dev can do every once in a while just to be sure.
<airlied>
AttributeError: 'CustomTarget' object has no attribute 'd_features'
<anholt>
having the partial runs catches a ton of regressions, if not every one.
<Venemo>
Likely wound't work for us
<jenatali>
We should probably do that for dozen...
<Venemo>
It's too easy to regress some corner case if only 1/3 of the CTS is there
<Venemo>
Maybe it's possible, but it'd be difficult to determine which 1/3 is necessary
<Venemo>
There're some things which are only tested by 1 test
<alyssa>
deqp-vk: 10000 tests for the same trivial function
<alyssa>
also deqp-vk: 1 test for complicated corner case you're likely to break
<jenatali>
Venemo: Would you expect a corner case like htat to get regressed by someone who's not looking at RADV? Otherwise if you were making a change that you thought might regress it, you can manually run the full run without blocking other MRs that probably won't
<anholt>
Venemo: that's why we have both. the pre-merge subset at least makes sure that people don't break everything.
<anholt>
(for example, it just prevented regressions in turnip from a core vulkan refactor that jekstrand was working on)
<jenatali>
And dozen, which is also using a subset
<anholt>
fractional isn't perfect, it's true. maintaining the full list is still work and playing catch-up.
<alyssa>
gdb ./deqp-vk # board gives up
<airlied>
dcbaker: got it working!
<Venemo>
jenatali: I think it can happen, but maybe I'm just paranoid
<anholt>
I keep hoping we can get some improvements that bring down runtime so that we can get more tests as full runs pre-merge. I'm hoping https://gitlab.khronos.org/Tracker/vk-gl-cts/-/issues/3565 ends up helping once we have it in our containers, though it'll take a bit of deqp-runner work to use it.
<jenatali>
IMO, don't let the perfect be the enemy of the good. Some coverage that runs pre-merge is better than none
<anholt>
jenatali: exactly.
tzimmermann has quit [Quit: Leaving]
<dcbaker>
airlied: sweet!
<Venemo>
The ultimate plan is to AFAIK run the whole thing, hopefully soon
<anholt>
Oh, the other thing on my mind for "how do we bring down test overhead" is tuning of render area size. For a lot of (for example) shader functionality tests, we could probably run at 64x64 instead of 256x256 and reduce the deqp swrast costs.
ybogdano has joined #dri-devel
<anholt>
(that's gles-only, though)
<Venemo>
Anyway, anholt in the a530_gl test runner there were some depth related fails on some depth related tests which have a similar name as some tests that I fixed for zink+radv and lima. Can you confirm these are not regressions?
Namarrgon has quit [Quit: WeeChat 3.5]
<mupuf>
anholt: daniels and I are working on it. We are about to source the necessary machines.
<anholt>
mupuf: excellent!
Namarrgon has joined #dri-devel
<mupuf>
We test other projects with the same machines. And a dxvk run is 2h long... too long for Marge to be stuck on
<anholt>
Venemo: sorry, not seeing which tests you're talking about that were also affected for lima
<mupuf>
So we need to dedicate some machines to Mesa
<mupuf>
(Until we implement a preemption mechanism)
<Venemo>
anholt: for example, this one: KHR-GLES3.texture_repeat_mode.depth_component16_49x23_1_mirrored_repeat,Fail
<danvet>
but I'm definitely not on top of kernel version jokes
saurabhg has quit [Ping timeout: 480 seconds]
<alyssa>
if you find a red-black tree
<alyssa>
call an arborist
frankbinns has quit [Quit: Leaving]
ahajda has joined #dri-devel
Duke`` has quit [Ping timeout: 480 seconds]
<HdkR>
alyssa: But how else am I to have an ordered map? :P
<alyssa>
HdkR: Pay a cartographer?
<HdkR>
Dang, they're all out to see
<HdkR>
sea
<icecream95>
alyssa: Can you even find any non-dEQP/Piglit "well-behaved applications" which make use of tiny buffer textures?
alyssa has quit [Quit: leaving]
YuGiOhJCJ has joined #dri-devel
danvet has quit [Ping timeout: 480 seconds]
danvet has joined #dri-devel
alyssa has joined #dri-devel
alyssa has quit []
alyssa has joined #dri-devel
<alyssa>
.
<HdkR>
,
alyssa has quit []
alyssa has joined #dri-devel
<alyssa>
I wrote what I wrote.
<alyssa>
I'm not willing to maintain those patches, and it doesn't look like any other NIR people are either.
<jekstrand>
icecream95: What is improved so much by giant buffer textures besides the PBO upload path?
<alyssa>
For the reasons I spelled out.
<jekstrand>
We might be able to fix PBO uploads to be able to support using a 2D linear texture.
ybogdano has joined #dri-devel
alyssa has quit [Quit: leaving]
mivanchev has quit [Quit: Leaving]
chaim has quit [Quit: Konversation terminated!]
kchibisov_ has quit [Ping timeout: 480 seconds]
ahajda has quit [Quit: Going offline, see ya! (www.adiirc.com)]
elongbug has quit [Read error: Connection reset by peer]
danvet has quit [Ping timeout: 480 seconds]
kchibisov has joined #dri-devel
icecream95 has quit [Ping timeout: 480 seconds]
apinheiro has quit [Quit: Leaving]
icecream95 has joined #dri-devel
<icecream95>
jekstrand: From a set of about 50 application traces I have, only one uses buffer textures, and that one can use SSBOs instead
<icecream95>
Now that Panfrost has dropped support for SSBOs in vertex shaders, that's less applicable a workaround, but needing buffer textures there should be less common
<icecream95>
So I suppose that just fixing PBO uploads/downloads should be enough
sul has joined #dri-devel
mbrost_ has quit [Ping timeout: 480 seconds]
rasterman has quit [Quit: Gettin' stinky!]
pcercuei has quit [Quit: dodo]
Peste_Bubonica has quit [Quit: Leaving]
Haaninjo has quit [Quit: Ex-Chat]
wv has joined #dri-devel
gawin has quit [Ping timeout: 480 seconds]
sul has quit [Ping timeout: 480 seconds]
sul has joined #dri-devel
wvanhauwaert has quit [Ping timeout: 480 seconds]
eukara_ has joined #dri-devel
eukara has quit [Read error: Connection reset by peer]